> If we're using Glib, then let's also use Glib's threading interface. It > gives us transparency over a variety of thread implementations and > platforms, and provides for graceful failure in case there is no thread > implementation at all.
The issue is that glib's thead pool won't work for an application server like dbmail, it is a pool or worker functions I wrote another program using glib's thread interface and it is a nightmare. I have a thread pool implementaion that is mostly from the pthreads book by o'reilly with real world updates and improments to it. It should be portable and if we make the threads configurable that would take care of the systems that don't allow for threads. > > > In the event of no thread implementation, or threads turned off, there > would basically be one thread per process and we could act as we do now. > In such a case, I think it would be ideal if the main parent process could > keep track of how many threads are running, and spawn processes until the > proper thread count is reached. On another note, dbmail shouldn't be run on systems without threads as off the top of my head I can't think of one that it would even compile on right now. Sun Solaris, linux and the bsd's have pthreads without any issues it is more of an issue to support glib on other system other than linux than it is to support pthreads. Just my thoughts as always.... -leif
