On Mon, Feb 18, 2002 at 04:40:49PM -0500, Tavin Cole wrote: > On Mon, Feb 18, 2002 at 08:20:32PM +0100, Oskar Sandberg wrote: > > On Mon, Feb 18, 2002 at 01:18:12PM -0500, Tavin Cole wrote: > > > On Mon, Feb 18, 2002 at 03:46:32PM +0100, Niklas Mehner wrote: > > > > I have implemented a new ThreadFactory, that only uses a fixed amount > > > > of > > > > threads. With the current PThreadFactory I have problems when under > > > > heavy load. > > > > The factory creates more and more threads, until freenet, java or my > > > > machine fail. > > > > > > This is because of bugs in the node that cause threads to get hung and > > > never return to the thread pool, so that it is forced to create more and > > > more overflow threads to satisfy the ticker. > > > > But the reason we implemented the "force after delay" feature was > > exactly to kill the deadlocks. In many ways, the anti-deadlock pool may > > be a better solution to this, and combined with the it can only be an > > improvement. In general, I think that Niklas' design seems very > > sensible. > > Nevertheless, coding the thread pool to resist bugs in the rest of the > node (and adding a lot of complication to it in the process) seems like > the wrong approach in the long run. > > -tc > > > > Switching to a thread pool that doesn't create overflow threads won't > > > solve this. It'll just make the node die sooner when the ticker can't > > > get any more threads.
Also, we could easily change things so that threads allocated from the thread pool never allocate more threads themselves. We just need to give the OCM its own thread like the Ticker and the Interfaces, and have that thread schedule threads to make outgoing connections. I think that we will need to give the OCM its own thread anyway so that it can dispatch threads to read messages off connections instead of dedicating a thread to each CH (which wastes valuable threads and is prone to all manner of synchronization bugs, with the interactions b/t the sendlock, receivelock, and OCM mutexes). -tc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20020218/1fa067a9/attachment.pgp>
