----- Original Message ----- From: "Jeff Varszegi" <[EMAIL PROTECTED]> > > > 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:[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]>
