> > 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? 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 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]>
