Well, after spending too much time reading code and whining I decided I should try to implement for a round to see what comes out. Check out experiments/machine... A few notes: * Everything that includes EventDispatcher or derives from EventManager will automatically be registered with the reactor. * The reactor''s iterate method will just run over all the registered dispatchers calling their iterate methods. This is done in a single thread, but it should be extremely easy to spin off another thread, run each dispatcher in it''s own thread, or with a pool of threads, or even remotely. * Anyone can send an event to a dispatcher. The event gets put on a queue, and when iterate is called all registered handlers will be called. (Handlers passed in arrays will be treated as a pipeline so their results are passed through to the next.) * The add_handler method supports all the variations I brought up in the last email. (block, method on some target, array of blocks, array of method names) * Timers are stored in a priority queue, and the loop sleeps depending on the next timer. * When a timer fires an event is sent to the dispatcher for that timer. The handlers are then called as normal. Take a look and see what you think. -Jeff
Cool! Was it fun? Will read and comment asap. On 5/23/06, Jeff Rose <jeff at rosejn.net> wrote:> > Well, after spending too much time reading code and whining I decided I > should try to implement for a round to see what comes out. Check out > experiments/machine... > > A few notes: > > * Everything that includes EventDispatcher or derives from EventManager > will automatically be registered with the reactor. > > * The reactor''s iterate method will just run over all the registered > dispatchers calling their iterate methods. This is done in a single > thread, but it should be extremely easy to spin off another thread, run > each dispatcher in it''s own thread, or with a pool of threads, or even > remotely. > > * Anyone can send an event to a dispatcher. The event gets put on a > queue, and when iterate is called all registered handlers will be > called. (Handlers passed in arrays will be treated as a pipeline so > their results are passed through to the next.) > > * The add_handler method supports all the variations I brought up in the > last email. (block, method on some target, array of blocks, array of > method names) > > * Timers are stored in a priority queue, and the loop sleeps depending > on the next timer. > > * When a timer fires an event is sent to the dispatcher for that timer. > The handlers are then called as normal. > > > Take a look and see what you think. > > -Jeff > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060523/de013328/attachment.htm
There are a lot of nice ideas in here. See my preliminary comments in machine/tests/NOTES. Also cf. core-model-3. On 5/23/06, Jeff Rose <jeff at rosejn.net> wrote:> > Well, after spending too much time reading code and whining I decided I > should try to implement for a round to see what comes out. Check out > experiments/machine... > > A few notes: > > * Everything that includes EventDispatcher or derives from EventManager > will automatically be registered with the reactor. > > * The reactor''s iterate method will just run over all the registered > dispatchers calling their iterate methods. This is done in a single > thread, but it should be extremely easy to spin off another thread, run > each dispatcher in it''s own thread, or with a pool of threads, or even > remotely. > > * Anyone can send an event to a dispatcher. The event gets put on a > queue, and when iterate is called all registered handlers will be > called. (Handlers passed in arrays will be treated as a pipeline so > their results are passed through to the next.) > > * The add_handler method supports all the variations I brought up in the > last email. (block, method on some target, array of blocks, array of > method names) > > * Timers are stored in a priority queue, and the loop sleeps depending > on the next timer. > > * When a timer fires an event is sent to the dispatcher for that timer. > The handlers are then called as normal. > > > Take a look and see what you think. > > -Jeff > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060524/79865f0d/attachment.htm
I responded to your notes in the same file... Francis Cianfrocca wrote:> There are a lot of nice ideas in here. See my preliminary comments in > machine/tests/NOTES. Also cf. core-model-3. > > On 5/23/06, *Jeff Rose* < jeff at rosejn.net <mailto:jeff at rosejn.net>> wrote: > > Well, after spending too much time reading code and whining I decided I > should try to implement for a round to see what comes out. Check out > experiments/machine... > > A few notes: > > * Everything that includes EventDispatcher or derives from EventManager > will automatically be registered with the reactor. > > * The reactor''s iterate method will just run over all the registered > dispatchers calling their iterate methods. This is done in a single > thread, but it should be extremely easy to spin off another thread, run > each dispatcher in it''s own thread, or with a pool of threads, or even > remotely. > > * Anyone can send an event to a dispatcher. The event gets put on a > queue, and when iterate is called all registered handlers will be > called. (Handlers passed in arrays will be treated as a pipeline so > their results are passed through to the next.) > > * The add_handler method supports all the variations I brought up in the > last email. (block, method on some target, array of blocks, array of > method names) > > * Timers are stored in a priority queue, and the loop sleeps depending > on the next timer. > > * When a timer fires an event is sent to the dispatcher for that timer. > The handlers are then called as normal. > > > Take a look and see what you think. > > -Jeff > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org <mailto:Eventmachine-talk at rubyforge.org> > http://rubyforge.org/mailman/listinfo/eventmachine-talk > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk
Jeff, what''s your IM address? On 5/24/06, Jeff Rose <rosejn at gmail.com> wrote:> > I responded to your notes in the same file... > > Francis Cianfrocca wrote: > > There are a lot of nice ideas in here. See my preliminary comments in > > machine/tests/NOTES. Also cf. core-model-3. > > > > On 5/23/06, *Jeff Rose* < jeff at rosejn.net <mailto:jeff at rosejn.net>> > wrote: > > > > Well, after spending too much time reading code and whining I > decided I > > should try to implement for a round to see what comes out. Check > out > > experiments/machine... > > > > A few notes: > > > > * Everything that includes EventDispatcher or derives from > EventManager > > will automatically be registered with the reactor. > > > > * The reactor''s iterate method will just run over all the registered > > dispatchers calling their iterate methods. This is done in a single > > thread, but it should be extremely easy to spin off another thread, > run > > each dispatcher in it''s own thread, or with a pool of threads, or > even > > remotely. > > > > * Anyone can send an event to a dispatcher. The event gets put on a > > queue, and when iterate is called all registered handlers will be > > called. (Handlers passed in arrays will be treated as a pipeline so > > their results are passed through to the next.) > > > > * The add_handler method supports all the variations I brought up in > the > > last email. (block, method on some target, array of blocks, array > of > > method names) > > > > * Timers are stored in a priority queue, and the loop sleeps > depending > > on the next timer. > > > > * When a timer fires an event is sent to the dispatcher for that > timer. > > The handlers are then called as normal. > > > > > > Take a look and see what you think. > > > > -Jeff > > _______________________________________________ > > Eventmachine-talk mailing list > > Eventmachine-talk at rubyforge.org <mailto: > Eventmachine-talk at rubyforge.org> > > http://rubyforge.org/mailman/listinfo/eventmachine-talk > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Eventmachine-talk mailing list > > Eventmachine-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/eventmachine-talk > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060524/616c3fa0/attachment.htm
Added some more notes to the same file. I like where you''re going with this API. I''m going to try to add the IO component, or at least specify it so you can add it. Also, the idea of event-routing needs to be understood clearly so we can decide whether it belongs in this project or not. On 5/24/06, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > Jeff, what''s your IM address? > > > On 5/24/06, Jeff Rose <rosejn at gmail.com> wrote: > > > > I responded to your notes in the same file... > > > > Francis Cianfrocca wrote: > > > There are a lot of nice ideas in here. See my preliminary comments in > > > machine/tests/NOTES. Also cf. core-model-3. > > > > > > On 5/23/06, *Jeff Rose* < jeff at rosejn.net <mailto:jeff at rosejn.net>> > > wrote: > > > > > > Well, after spending too much time reading code and whining I > > decided I > > > should try to implement for a round to see what comes out. Check > > out > > > experiments/machine... > > > > > > A few notes: > > > > > > * Everything that includes EventDispatcher or derives from > > EventManager > > > will automatically be registered with the reactor. > > > > > > * The reactor''s iterate method will just run over all the > > registered > > > dispatchers calling their iterate methods. This is done in a > > single > > > thread, but it should be extremely easy to spin off another > > thread, run > > > each dispatcher in it''s own thread, or with a pool of threads, or > > even > > > remotely. > > > > > > * Anyone can send an event to a dispatcher. The event gets put on > > a > > > queue, and when iterate is called all registered handlers will be > > > called. (Handlers passed in arrays will be treated as a pipeline > > so > > > their results are passed through to the next.) > > > > > > * The add_handler method supports all the variations I brought up > > in the > > > last email. (block, method on some target, array of blocks, array > > of > > > method names) > > > > > > * Timers are stored in a priority queue, and the loop sleeps > > depending > > > on the next timer. > > > > > > * When a timer fires an event is sent to the dispatcher for that > > timer. > > > The handlers are then called as normal. > > > > > > > > > Take a look and see what you think. > > > > > > -Jeff > > > _______________________________________________ > > > Eventmachine-talk mailing list > > > Eventmachine-talk at rubyforge.org <mailto: > > Eventmachine-talk at rubyforge.org> > > > http://rubyforge.org/mailman/listinfo/eventmachine-talk > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Eventmachine-talk mailing list > > > Eventmachine-talk at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/eventmachine-talk > > > > _______________________________________________ > > Eventmachine-talk mailing list > > Eventmachine-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/eventmachine-talk > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060524/bc1b91e2/attachment-0001.htm
How are callbacks defined in such a model? We''ve been assuming
we need them because Twisted has them, but most of their functionality
is probably present in the handler mechanism we already have.
The exception: sending responses to events, but we still haven''t
defined
any event types that need to be responded to. (That will come soon
enough.) Rather than a callback, we may want to send another event that
is somehow correlated with the first one.
* I''m not sure about whether we would need them, or how they would be
best implemented. It seems like the most direct way would be to attach
them to events, but for now maybe we could just go with what we have,
and cross that bridge when we get to it...
The Timeout class defines a straightforward Dispatcher, but it bothers
me that it adds a custom implementation of add_handler. Did you do this
only to sugar the :timer_expired event type? Or is there a more
fundamental reason?
* Yeah, that was just to make it easier so every time you create a timer
you don''t have to lookup the stupid event type, but I agree
it''s maybe
poor form to create a general event handling interface and then not
stick to it. Maybe we should have methods with different names?
Timeout adds an construct that is orthogonal to EventDispatcher in
order to get the timing basis. This is the combination of egister_timer,
the priority queue, and the fire_timers method which has to be invoked
by the reactor. Something analogous has to be defined for I/O Dispatchers.
* Exactly. In the end each processing stage or component could have
it''s own infrastructure for doing I/O, timing, graphics etc., but they
can share the event interface.
Why do you need the external PQueue implementation? For one thing, it''s
GPL and we need EventMachine to be either Ruby-licensed or LGPL.
But what does PQueue give you that couldn''t get simply by adding timers
to a Ruby array and then calling sort! {|a,b| a.expiration <=>
b.expiration}?
* Haha, you are 100% right. I just had it laying around from my event
based simulator where there are thousands or more events in the system
at a time, and the built-in sort would be to expensive every insert.
Unless it is a bottleneck it''s stupid to include these things. I also
would like to make it ruby-license compatible too...
I think it''s better to have custom names in subclasses of EventDispatch rather than redefining add_handler. Let''s keep the base-class API as clean as we can. Callbacks: it would be great if we find out we don''t need ''em. One more win for Ruby. On 5/24/06, Jeff Rose <rosejn at gmail.com> wrote:> How are callbacks defined in such a model? We''ve been assuming > we need them because Twisted has them, but most of their functionality > is probably present in the handler mechanism we already have. > The exception: sending responses to events, but we still haven''t defined > any event types that need to be responded to. (That will come soon > enough.) Rather than a callback, we may want to send another event that > is somehow correlated with the first one. > > * I''m not sure about whether we would need them, or how they would be > best implemented. It seems like the most direct way would be to attach > them to events, but for now maybe we could just go with what we have, > and cross that bridge when we get to it... > > The Timeout class defines a straightforward Dispatcher, but it bothers > me that it adds a custom implementation of add_handler. Did you do this > only to sugar the :timer_expired event type? Or is there a more > fundamental reason? > > * Yeah, that was just to make it easier so every time you create a timer > you don''t have to lookup the stupid event type, but I agree it''s maybe > poor form to create a general event handling interface and then not > stick to it. Maybe we should have methods with different names? > > Timeout adds an construct that is orthogonal to EventDispatcher in > order to get the timing basis. This is the combination of egister_timer, > the priority queue, and the fire_timers method which has to be invoked > by the reactor. Something analogous has to be defined for I/O Dispatchers. > > * Exactly. In the end each processing stage or component could have > it''s own infrastructure for doing I/O, timing, graphics etc., but they > can share the event interface. > > Why do you need the external PQueue implementation? For one thing, it''s > GPL and we need EventMachine to be either Ruby-licensed or LGPL. > But what does PQueue give you that couldn''t get simply by adding timers > to a Ruby array and then calling sort! {|a,b| a.expiration <=> > b.expiration}? > > * Haha, you are 100% right. I just had it laying around from my event > based simulator where there are thousands or more events in the system > at a time, and the built-in sort would be to expensive every insert. > Unless it is a bottleneck it''s stupid to include these things. I also > would like to make it ruby-license compatible too... > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >