On Mon, Aug 07, 2000 at 01:42:46PM +0700, Oskar Sandberg wrote: > On Fri, 04 Aug 2000, Scott G. Miller wrote: > <> > > Ah, I believe your right. The solution is to not use a BlockingQueue, but > > rather a BlockingStack. That way reclaimed threads get used in preference > > over new threads. > > Speaking of this, I keep forgeting to ask, should I go to the ThreadPool thing > to get threads that are started within the message handeling? It seems a > little > unnecessary that we have this advanced thread handler so as to recycle > threads, > but each transfer starts and ends two new Conduit threads. > > The problem is of course that the node if more or less comitted to running > these threads, it can't fail or lock if all threads are in use. Yeah, but you can create a second pool for the conduits if you like, and set its maxThreads to 0. This will let it run unbounded, keeping up to 25 threads in the pool for re-use, but never limiting the number of running threads.
> > I think most JVMs can use internal threads if you ask them (not that I know > how). The Sun JDK can do this with -green > > If he really wants to code so bad I'm sure we can find something for him. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000807/efb2a9f6/attachment.pgp>
