On Feb 25, 2011, at 5:01 PM, Michael Kogan wrote: > Multiple threads interacting with the reactor, since jetty (in my case) has a > thread pool to service clients. Making register/unregister to be synchronzied > or mutexed is an issue, I think, since to have that be usefull, I would have > to use mutexes/synchronization in the polling loop. That is get a lock > before querying a socket (make sure it is not getting removed). > > Mike. > > On Feb 25, 2011, at 2:24 PM, Chuck Remes wrote: > >> If you are using multiple threads to interact with your reactor, then you're >> actually building something else. If you're worried about a race condition, >> just make your calls to register/unregister synchronized or put your own >> mutex/lock around them.
Mike, I solved this in the 0mq reactor that I wrote in Ruby using the following technique. I provide a single method to allow non-reactor threads to schedule work on the reactor workloop. In my codebase it's called #next_tick and it takes a block/lambda/anonymous function. This is the only place where a mutex is exposed to an external caller. The method pushes the lambda onto an array in a thread-safe way, and on each 'tick' through the reactor loop it pops each lambda off the array and executes it. This technique "serializes" all access to reactor-resources from outside code, so it eliminates the possibility of any race conditions like you mention above about querying sockets. I don't know if this is feasible in Java since I'm not a very experienced Java programmer, but perhaps the general idea is applicable. If you are curious to see the code (Ruby is super easy to read), take a look here: https://github.com/chuckremes/zmqmachine/blob/master/lib/zm/reactor.rb#L146 and https://github.com/chuckremes/zmqmachine/blob/master/lib/zm/reactor.rb#L379 I hope this helps. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
