Hi,
I''m attempting to use EM from ''C'', but I notice the
event
constants:
enum { // Event names
TIMER_FIRED = 100,
CONNECTION_READ = 101,
CONNECTION_UNBOUND = 102,
CONNECTION_ACCEPTED = 103,
CONNECTION_COMPLETED = 104,
LOOPBREAK_SIGNAL = 105
};
...appear only inside the EventMachine_t C++ class.
Might this be an oversight or am I overlooking something?
Also, just out of curiosity, I was wondering what the rationale
might be for passing the uuid for TIMER_FIRED in the 3rd argument
of event_callback rather than the 1st argument?
Thanks,
Bill
On 3/30/07, Bill Kelly <billk at cts.com> wrote:> > Hi, > > I''m attempting to use EM from ''C'', but I notice the event > constants: > > enum { // Event names > TIMER_FIRED = 100, > CONNECTION_READ = 101, > CONNECTION_UNBOUND = 102, > CONNECTION_ACCEPTED = 103, > CONNECTION_COMPLETED = 104, > LOOPBREAK_SIGNAL = 105 > }; > > ...appear only inside the EventMachine_t C++ class. > > Might this be an oversight or am I overlooking something?So you''re trying to use the EM library without Ruby in the picture at all? Interesting, that case was definitely part of the design, but I''m not sure anyone has ever done except me in very early testing! If that''s what you''re trying to do, let me know and we''ll work out the problems. There may be others beyond the placement of these constants. Also, just out of curiosity, I was wondering what the rationale> might be for passing the uuid for TIMER_FIRED in the 3rd argument > of event_callback rather than the 1st argument?Actually there was a rationale, but I can''t remember it now! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070330/51e269a8/attachment-0001.html
On 3/30/07, Bill Kelly <billk at cts.com> wrote:> > Also, just out of curiosity, I was wondering what the rationale > might be for passing the uuid for TIMER_FIRED in the 3rd argument > of event_callback rather than the 1st argument?I remember. Here''s the dispatch code. Note that the first parameter is always a connection binding and is called that in these code paths, while the third one is always data. It seemed more correct to use the data field for the timer descriptor, which strictly speaking isn''t a connection binding. You could easily have argued it the other way. private def EventMachine::event_callback conn_binding, opcode, data case opcode when ConnectionData c = @conns[conn_binding] or raise ConnectionNotBound c.receive_data data when ConnectionUnbound if c = @conns.delete( conn_binding ) c.unbind elsif c = @acceptors.delete( conn_binding ) # no-op else raise ConnectionNotBound end when ConnectionAccepted accep,blk = @acceptors[conn_binding] raise NoHandlerForAcceptedConnection unless accep c = accep.new data @conns[data] = c blk and blk.call(c) c # (needed?) when TimerFired t = @timers.delete( data ) or raise UnknownTimerFired t.call when ConnectionCompleted c = @conns[conn_binding] or raise ConnectionNotBound c.connection_completed when LoopbreakSignalled run_deferred_callbacks end end -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070330/60ca6d99/attachment.html
Hi Francis,> So you''re trying to use the EM library without Ruby in the picture > at all? Interesting, that case was definitely part of the design, > but I''m not sure anyone has ever done except me in very early > testing! If that''s what you''re trying to do, let me know and we''ll > work out the problems. There may be others beyond the placement of > these constants.Yep! My OpenGL/GUI process is pure C. My ruby code is in a separate process. Both processes use EM to talk to one another. As I recall (I did this several months back) I only needed a few #ifdef''s to get EM compiling w/out targeting ruby. So far, it seems to be working, I can create timers and connect to TCP servers and my event_callback is called as expected. (I am seeing some behavior I can''t explain yet where a timer is firing more rapidly than it should... but I haven''t tried to debug that yet.) Regards, Bill
From: Francis Cianfrocca> > On 3/30/07, Bill Kelly <billk at cts.com> wrote: > > Also, just out of curiosity, I was wondering what the rationale > > might be for passing the uuid for TIMER_FIRED in the 3rd argument > > of event_callback rather than the 1st argument? > > I remember. Here''s the dispatch code. Note that the first parameter > is always a connection binding and is called that in these code > paths, while the third one is always data. It seemed more correct to > use the data field for the timer descriptor, which strictly speaking > isn''t a connection binding. You could easily have argued it the > other way.OK, thanks. One thought: When/if GUI events are integrated into EM, they won''t be connection bindings either--but they will probably need the data field for their own purposes. Regards, Bill
On 3/30/07, Bill Kelly <billk at cts.com> wrote:> > One thought: When/if GUI events are integrated into EM, they > won''t be connection bindings either--but they will probably > need the data field for their own purposes. > > > Regards, > > Bill > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >That''s a good point -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070330/67bd3b93/attachment.html