commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] Pleasedtameetcha, and a couple of questions
Date Sun, 17 Nov 2002 00:32:35 GMT
----- Original Message -----
From: "Jeff Varszegi" <jvarszegi@yahoo.com>
> > > The second is a double-ended queue
> > May be too specialised. Don't know without looking. Does it implement
our
> > Buffer interface?
>
> Did you have a chance to take a look?  Anyone, anyone?
Unfortunately we are all time pressurised, and at the moment it seems as
though I'm the only one keeping an eye out for [collections] which isn't
ideal.


> The Buffer interface is very simple, and
> it wouldn't be hard to make a collection implement it, but it is opposed
to the problem that is
> solved by the queue I sent to the list.  I created it to serve as a
double-ended queue (which has
> very wide application) and also to serve as an information conduit/buffer
between separate threads
> in an application.
The quick look I did take made me wonder if this would fit better in a
[thread] project, rather than generic [collections]. Not sure. It depends on
whether the most significant part is the threading or the double-ended part.
(Of course we haven't really got an active [thread] project ;--)

Stephen

> The fact that Buffer always throws an exception if a read attempt is made
without something being
> in the queue woudl be a detriment if the queue were being used in this
way; also, the Buffer
> interface says nothing about peeking.  The peeking is okay, since that
could be behavior just not
> guaranteed by the interface.
>
> I modeled the remove/peek methods after JMS queue methods where you can
specify a certain number
> of milliseconds to wait.  This is useful because you immediately get a
return whenever there is
> one, and you are given the chance to interrupt your waiting-for-work in
order to poll for state
> changes (like would happen when you're application's shutting down).
>
> Know what I mean?  If a Buffer always returns something immediately or
throws an exception, then
> to accept work from a Buffer means that you must implement your own
sleeping loop outside of read
> calls to the Buffer.  And, of course, when you're sleeping you can't read,
so you're guaranteed to
> get any result from a Buffer an average of half your sleep interval after
you could've received it
> in an optimal situation.
>
> Sorry for being so blasted unintelligible, but I'm coping with a raging
cold here.
>
> Your friend,
> Jeff
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - Let the expert host your site
> http://webhosting.yahoo.com
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message