Peter Donald wrote:
On Sat, 15 Dec 2001 08:43, Berin Loritsch wrote:
I would like to have reactions on the Blocking and EventDropping issues
though....
Event dropping should be an application specific thing. However I am not
sure why Blocking and non-Blocking versions of interfaces need to be
separate. I haven't looked closely at the proposal though - will try to
do so real soon now ;)
Yes, but should they affect the way a system is written? For instance,
the basic operation of dequeue() doesn't change. Is it sufficient
for the blocking timeout to be set once for the pipeline, or should it be
set for *each* dequeue() method? Personally, I lean toward setting it
once.
Hmmm I guess so. What I was thinking is that "void enqueue()" should either
always pass (and thus block) or throw an exception. If you wanted more
control (ie making sure it doesn't block) then you should use tryEnqueue
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....
--
"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]>
