On Sun, 2004-03-07 at 22:30, Niclas Hedhman wrote: > thread barrier ->| > | > | registration > | +-----------------+ > | | | > | V | > +------------+ +--|----+ +---------+ > request | Network | write | queue | event | Request | > --------> | Management | ------->| | |------> | Service | > +------------+ +--|----+ +---------+ > | > | > > Is this anything like what is going on? > > * Registration of the RequestService(s) to the queue. > * Request comes in which the network routines places in the queue > * The queue fire events to registered parties. > > And your "problem" is that the 'queue' fills up quickly by the network > routines, since there is nothing emptying them in the initial stages?
Yeah, that's pretty much it. > IF this is the overall picture, and that the "queue" is a separate component, > I would make it the "coordinator", so that the "Network Management" registers > itself there as well, to be notified for "RegistrationEvents", containing > enough information on when it is possible to enable the incoming connections. > > thread barrier ->| > | > | > RegistrationListener | RequestListener > registration | registration > +----------------+ | +-----------------+ > | | | | | > | v | v | > +------------+ +--|----+ +---------+ > request | Network | write | queue | event | Request | > --------> | Management | ------->| | |------> | Service | > +------------+ +--|----+ +---------+ > | > | > > Does this helps? > This would probably be a better long-term solution, though in my case it would be a real pain to use without a system that could deploy the services in a way that understood the queue dependencies. It's something I'm planning to work toward. Meanwhile, it would take way more time to code than I have until my deadline :). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
