Coroutine Manager

Lets say I have the following code:

function example()
    os.pullEvent("key")
    print("HIT")
end

local co = coroutine.create( example )

function manager()
    while true do
        local e = os.pullEvent()
        coroutine.resume( co, e )
    end
end

manager()

the example function will print "HIT" no matter what event the manager catches, even though the function has called os.pullEvent with a filter of "key". What changes do I need to make the manager to prevent this from happening? I have a feeling that if I knew what the filter was I could manually check if the event is the same and if it is then resume it, but I don't know how to find out what filter they set in pullEvent/pullEventRaw/coroutine.yield.

I think you have to replace

local e = os.pullEvent()

With

local e = os.pullEvent("key")

>Edit<
Nvm i tested it in cc, it didnt work :/

I see what you are getting at, but the manager would (in the big picture) be catching all events and managing more than one coroutine.

After looking at the parallel API, I found that the coroutine.resume() returns a boolean (false if error) and a variable that is either the error string(if it crashed) OR the filter inside the pullEvent.

So as a result, the manager just needs to store the second parameter and check if the event it catches matches that, if it doesn't, simply ignore it.

Thanks for expressing interest, but unfortunately the solution is not going to be that simple apparently xD. Ill post the finished code here if I remember.

Complete Code (On my phone so this is just proof of concept, although a more complex version of this using tables and IDs works perfectly)

function example()
os.pullEvent("key")
print("HIT")
end
local co = coroutine.create( example )
function manager()
local sFilter = false
while true do
  local e = os.pullEvent()
  if sFilter and sFilter == e or not sFilter then
   coroutine.resume( co, e )
					    sFilter = false
  end
end
end
manager()

coroutine.yield() returns coroutine.resume()'s parameters, and vice versa. You hence need to update your filter based on what you get back from resume().

This is an example of how you can run a single coroutine to completion. I've also started typing out a proper coroutine guide, but I kinda got sidetracked and haven't gotten around to finishing it just yet…

Yeah, that's what the manager is doing, but because its so much larger the example above was quickly typed up to demonstrate the concept.

The filter is passed back as the result of the resume call. It will be the second argument.