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" <avalon-dev@jakarta.apache.org>
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]>
