Chad Stansbury wrote: > Do you intend a given Sink to be utilized by several processes, each of > which might want to specify a different timeout value? If so, then the > should be passed as a parameter. Otherwise, a member variable is fine. > Personally, I would err towards flexibility and overload the dequeue methods > to allow one to either specify a timeout value, or to utilize the default > (which is set at creation time).
That's the issue I am wrestling with. In the full version of the SEDA architecture where you have multiple Stages connected by queues, I don't find any real value in blocking a thread until an event comes because that thread can be used for a different stage to process it's events. However, in the simple CommandQueue that I am going to implement, the control events will be within one queue, with one thread for that implementation. In that case, I can see blocking the dequeue operation because the thread is mostly going to be used strictly in that context. However, if the command queue is used in the larger system again, blocking is again not good. It is quite easy to perform the blocking within the CommandQueue's thread, or simply to tell it to sleep. > > Chad Stansbury > > ----- Original Message ----- > From: "Berin Loritsch" <[EMAIL PROTECTED]> > To: "Avalon Developers List" <[EMAIL PROTECTED]> > Sent: Friday, December 14, 2001 3:09 PM > Subject: Re: [Review] Event Queues > > > >>Berin Loritsch wrote: >> >> >>>Peter Donald wrote: >>> >>>Remember this is dequeue(). >>> >>>The Sink side of the equation is active, and therefore a call to pop >>> > events > >>>off the queue would block if the timeout was set. >>> >>>The Source side of the equation is passive, and therefore a call to push >>>events on the queue never block, but will throw an exception unless >>>tryEnqueue() is called. >>> >>>In essence, enqueue() can assert backpressure if the queue is not >>> > emptied > >>>or processed quick enough. Dequeue can block until there are actual >>>events to dequeue ( or there are X events to dequeue in the case of >>>dequeue( X ) ). >>> >>>I will merge the interfaces with some of the ideas talked about today, >>> > and > >>>let me know if you like it better.... >>> >> >> >>I committed a less cluttered queue interface, which should be cleaner >>than the SEDA version, and more semantically correct. I also took your >>advice regarding virtualization. >> >>I am particularly interested if you are satisfied with the setTimeOut() >>method, or if you would rather a different approach. >> >> >> >> >>-- >> >>"They that give up essential liberty to obtain a little temporary safety >> deserve neither liberty nor safety." >> - Benjamin Franklin >> >> >>-- >>To unsubscribe, e-mail: >> > <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: >> > <mailto:[EMAIL PROTECTED]> > >> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > . > > -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
