Skip to content
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

Closed
xopxe opened this issue Aug 13, 2013 · 2 comments
Closed

General API questions: waiting #2

xopxe opened this issue Aug 13, 2013 · 2 comments

Comments

@xopxe
Copy link

xopxe commented Aug 13, 2013

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.

@fab13n
Copy link
Contributor

fab13n commented Aug 13, 2013

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:

local M = { } -- the module table
local sched = require 'sched'

function M.one()
    local ev = sched.wait(M, 'someevent')
end

funtion M.two()
    sched.signal(M, 'someevent')
end

--[[ ... ]]

return M

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.

@xopxe
Copy link
Author

xopxe commented Aug 13, 2013

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.
In practice, the users solve the namespacing problem on their own, having modules export what signals they offer:

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 :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants