So could a possible fix be to call event_base_once() with callback==consider_read and timeout == 0 to make sure it gets processed in the next iteration of the loop?
On Thursday, 22 December, 2011 at 8:57 PM, Mark Ellzey wrote: > On Thu, Dec 22, 2011 at 01:33:28PM +0500, Haseeb Abdul Qadir wrote: > > What you guys mean when you say 'build correct infrastructure'? Does it > > mean the ability to schedule callbacks and guarantee that callbacks will > > called in the order they've been queued? For example a timer callback with > > a timeout of 0 is usually enough to enough to defer processing to the next > > iteration of the event loop on other platforms (i.e Windows' message loop > > and Cocoa runloops). > > > This is off-topic of this thread. But if you put events in a deferred > state, things are inserted in a tailq, so technically they will be > ordered. > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net > (mailto:majord...@freehaven.net) with > unsubscribe libevent-users in the body. > >
