pullEvent isn't resumed when run in a coroutine

[RobertBouillon]

Minecraft Version

1.19.x

Version

1.101.4

Details

Description

If os.pullEvent is called in a coroutine, it hangs and is never resumed by the cooperative scheduler.

I could be misunderstanding something here, so I apologize if I am. My understanding is that calling pullEvent should yield until an event occurs. When an event occurs, the task scheduler should call coroutine.resume(co,<event args>...) on the coroutine that has yielded.

I don't want to use the parallel API because its methods block - I need to run my code in a loop and I want to avoid blocking.

local function CheckInput()
  while true do
    print("Waiting...")
    local evt, key = os.pullEvent("key")
    print(key)
  end
end

local co = coroutine.create(CheckInput)
coroutine.resume(co)  --Start
while true do
  --local _, key = os.pullEvent("key")
  --print("Works in main loop")
  sleep(0)
end

pullEvent works as expected on the computer's coroutine, but it won't work on a custom one. Am I missing something that might put my custom coroutine on the scheduler's queue?

[SquidDev]

So Lua doesn't really have any notion of coroutine scheduler. When you resume a coroutine, it runs that coroutine until it yields, and then restores control to the caller. This means resuming a coroutine is always going to be a "blocking" operation.

Of course, that doesn't mean you can't write your own! Typically what one does is wrap the whole program in a coroutine dispatch loop, and then run the main body of the program a coroutine. Then when you need to run background code, you can add a coroutine to the dispatcher.

There's a very simple example of this in this comment, but there's lots of alternative designs you can go for, like metis's await module¹.

Footnotes

1. Not really recommending this code - the API not very well designed - but it's a good example. ↩

[RobertBouillon]

This I super helpful, thanks so much for writing such a detailed reply.

This explains why the parallel API is recommended 99.9% of the time - it's a dispatcher. I reworked my code a bit and that solved my problem with the parallel API.

The code examples were fantastic and really helped me understand the "how" and the "why." I really appreciate you taking the time to provide the links - you could have just pointed me to the parallel API and you didn't. I have a deeper understanding of the relationship between coroutine.yield and coroutine.resume as they relate to the context of the computer's main routine and the events provided by its dispatcher.

(Note that the 3 links pointed to the same URL for some reason, but it was exactly what I needed)