New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General API questions: waiting #2
Comments
|
My guess is, your users typically work on smaller projects than we do with Mihini. You can think of emitters as namespaces (you can guarantee their uniqueness by using a table as emitter, for instance the module sending the event). If you don't need them locally, I'd suggest that you use the following Lua-5.2-friendly pattern: It's not much heavier to read and write than an emitter-free variant, and it will avoid nasty bugs if you ever start combining sched-aware modules together. Also, notice that we don't plan to keep providing a separate distribution of luasched; the code is now shipped as part of Mihini. Which means that the most appropriate place to reach developers is the Mihini mailing list. |
|
I see... In my API the emitter is not specified by the user when signaling: the emitter is the task that emits the signal. So, when waiting you specify what task you want to listen from. This is how it looks: local task1 = sched.run (function()
sched.signal('ev') --notice no emitter parameter
)
local emitter, signal = sched.wait(task1, 'ev')It does look pretty on sample programs. M = {}
M.signal1 = {}
M.do_stuff = function ()
sched.signal(M.signal1)
end
return M
--users of module M do "sched.wait('*', M.signal1)"I'll have to think about this. (and subscribe to mihini mailing list, thanks for the pointer :) ) |
I looked for an adequate place to make this question but didn't find one... If there is one, i would be grateful to be pointed there.
I've written a sort of spin-off of luasched called Lumen which has been used in a couple projects. One thing I noticed is that people usually layout the programs as to do no need the "emitter" parameter when waiting for signals. Typically, the signal itself is a singleton which can be emitted by the tasks (usually a single one) that make sense. So most of the time wait('*', signal) works just right. In the few cases an emitter was specified, it could be very easily refactored to not need one.
I was thinking on rewriting Lumen with a simplified API, to make it easier to use and faster. Dropping the emitter from wait specification is a candidate, and was wondering what was your experience in how this is used in real apps.
The text was updated successfully, but these errors were encountered: