You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
localthread=require("thread")
localco=coroutine.create(function()
coroutine.yield(1)
end)
localfunctionthreadBody()
-- to allow the parent process to exitos.sleep(1)
print(coroutine.resume(co))
endthread.create(threadBody):detach()
The coroutine is created in a process (I'll refer to it as the Process), and I think /boot/01_process.lua registers it in the instances table of the Process. The rest of the code just makes it so that I resume the coroutine after the Process dies a peaceful death. When it does, its list of instances goes poof. So when I finally do a coroutine.resume, the coroutine isn't listed anywhere. And then assert(process.info(_coroutine.running()), "thread has no proc") in /boot/01_process.lua throws a tantrum because it can't find the associated process info.
The same thing happens if I try resuming an orphaned coroutine in an event listener, etc. (My workaround in the meanwhile is to create the coroutine inside a thread body and detach the thread.)
Since coroutine.resume has an exception for orphans, I believe the other coroutine. functions, like yield, should also have such an exception.
The text was updated successfully, but these errors were encountered:
this isn't how to manage coroutines, this is not a bug
you have no code that calls coroutine.resume(co) a 2nd time.
oc.resume in print is the first time it runs
the, in the co function, you coroutine.yield
There is no intention to change this behavior, this is exactly how coroutines are supposed to behave
If you want "threads" that wake themselves back up, you want the thread library.
With all due respect, I'm aware of how coroutines are supposed to work. And please note that I didn't complain how the coroutine is not resumed the second time. The code above doesn't resume it twice because it doesn't need that to reproduce the bug. Moreover, the code won't even be able to do so, as the coroutine dies because of the bug — and you cannot resume a dead coroutine.
The issue is about being unable to call coroutine.yield from within a coroutine that is run inside a detached thread.
Therefore I respectfully ask you to reconsider your decision to close this issue. The bug is still present.
I'll start with a repro:
The coroutine is created in a process (I'll refer to it as the Process), and I think
/boot/01_process.lua
registers it in theinstances
table of the Process. The rest of the code just makes it so that I resume the coroutine after the Process dies a peaceful death. When it does, its list of instances goes poof. So when I finally do acoroutine.resume
, the coroutine isn't listed anywhere. And thenassert(process.info(_coroutine.running()), "thread has no proc")
in/boot/01_process.lua
throws a tantrum because it can't find the associated process info.The same thing happens if I try resuming an orphaned coroutine in an event listener, etc. (My workaround in the meanwhile is to create the coroutine inside a thread body and detach the thread.)
Since
coroutine.resume
has an exception for orphans, I believe the othercoroutine.
functions, likeyield
, should also have such an exception.The text was updated successfully, but these errors were encountered: