On Mon, Jul 6, 2009 at 10:20 PM, Paul Querna<[email protected]> wrote: > I am looking for an alternative that doesn't expose all this crazyness > of when to free, destruct, or lock things. The best idea I can come > up with is for each Connection, it would become 'semi-sticky' to a > single thread. Meaning each worker thread would have its own queue of > upcoming events to process, and all events for connection X would sit > on the same 'queue'. This would prevent two threads waiting for > destruction, and other cases of a single connection's mutex locking up > all your works, essentially providing basic fault isolation. > > These queues could be mutable, and you could 'move' a connection > between queues, but you would always take all of its events and > triggers, and move them together to a different queue. > > Does the 'connection event queue' idea make sense?
I think I see where you're going with this...being so dependent upon mutexes seems...like going into a jungle full of guerillas armed with only a dull kitchen knife. So, a connection gets assigned to a 'thread' - but it has only two states: running or waiting for a network event. The critical part is that the thread *never* blocks on network traffic...all the 'network event' thread does is detect "yup, ready to go" and throws it back to that 'assigned' thread to process the event. Seems trivial enough to do with a serf-centric system. =) > I'm not sure I'm expressing the idea fully over email.... but I'll be > at OSCON in a few weeks if anyone wants beer :) I'll take you up on the beer and we can mull it over... -- justin
