On Mon, May 2, 2011 at 7:18 PM, D.P. <
pizdes@xxxxxxxxx> wrote:
> Hi, I have a question regarding adding an event from a different thread
> (different from the one event_base_dispatch was called).
> Initially I create an event_base, add a listener socket to it, and do
> event_base_dispatch. When a listener socket gets an incoming connection, it
> will add the new client socket (from inside the callback) to event_base.
> Everything works as expected up to this point (i.e. client socket callback
> is invoked whenever there is data
> to read, and listener socket is invoked whenever there is another client
> trying to connect.) Now I add another socket using event_add, but from a
> different
> thread. Now let's say some data arrives at this socket that I have just
> added. It seems that a callback for this socket will only get invoked
> *after* there
> is some activity on the other two sockets (listener or client from before).
> So if there is no activity at all on the two sockets that were added before,
> the callback
> for this new socket will never get called. I tested the same code on OS X
> with kqueue and poll backends, and on Linux with epoll and poll. This does
> not happen
> with epoll (the new socket callback will be fired even if there is no
> activity on the other two), but does happen with kqueue and poll. Is there
> anything I can do
> to "force" an immediate refresh (while the event loop is running) of the set
> of watched sockets for systems that use kqueue or poll?