on task completion emit `DIE` and `FINISH` signals lazily?

[lePereT]

I'm trying to wait until two Lumen tasks have finished, basically using the following code:

a = sched.new_task(function()
    -- Does some work
end)

b = sched.new_task(function()
    -- Does some work
end)

while a.status == 'ready' or b.status == 'ready' do
    sched.wait({a.EVENT_DIE, a.EVENT_FINISH, b.EVENT_DIE, b.EVENT_FINISH})
end 

This doesn't work, because the following lines in sched.lua emit these signals before changing the status of the task.

https://github.com/xopxe/lumen/blob/efa8e6b7b8691b44f6ab210fd8e5be352d5ab8c2/sched.lua#L133

Therefore we have the strange situation where anything woken up by a signal saying a task has ended, when checking the status of the task, will find that the task remains ready. Should the status be changed earlier? Or should the signals be emitted lazily? Or is there a better way of doing what I'm attempting?

[lePereT]

For the moment I've worked around this by examining the status of the underlying coroutines but this seems a little hacky

[xopxe]

Yes, I agree that your code seems perfectly reasonable. As you say there are two solutions, either mark the task as dead as soon as we know the coroutine is dead, or delay the signal until after the death of the task is completed. The first solution would be move the line 144 (taskd.status='dead') to line 129. The other would be changing the four emit_signal on lines 133, 134, 138 and 139 to M.schedule_signal. I believe the first option of marking the task as dead before signalling is the simplest way. Could you test it?

[lePereT]

I will! (I've also seen the discussion on the Lua mailing list re the Trio implementation that's being done. It seems interesting but it still seems to suffer from the function colouring problem. I'd wondered whether you'd seen Andy Wingo's post on fibers (CML) in Lua. It's a very beautiful thing https://wingolog.org/archives/2018/05/16/lightweight-concurrency-in-lua . There's a fuller implementation in the Snabb fibers library that he authored https://github.com/snabbco/snabb/tree/master/src/lib/fibers . I've made some of the code there standalone but haven't had time to do the epoll stuff. Anyway, though this might be of interest to you, as some nice building blocks)

[xopxe]

Thanks, I'll look into it! Off course, as you say such a system becomes useful only when it is integrated with some OS library. And that is actually the part of Lumen that I find ugliest, the Luasocket/nixio integration is nasty.

[xopxe]

committed ## e56e64c75ee92092cd087b633d5a173f01cde210

[lePereT]

Sorry I didn't get time to test this Xopxe!

On Sat, 12 Nov 2022, 11:54 Jorge, @.***> wrote:

committed ## e56e64c https://github.com/xopxe/lumen/commit/e56e64c75ee92092cd087b633d5a173f01cde210

— Reply to this email directly, view it on GitHub https://github.com/xopxe/lumen/issues/23#issuecomment-1312384467, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFUW5B5PDXVOMVFDVXWBU3WH4Z3RANCNFSM6AAAAAAQ62F44A . You are receiving this because you authored the thread.Message ID: @.***>