Leif Jackson wrote:
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.
From my perspective this is a matter of reputation. I don't know anything much about writing multi-threaded
implementations in c. My experience is limited to java.
But any code we maintain, must be maintainable. Being open to new things, I'm perfectly willing to take your
word for it if you say your code is better than't glib's implementation, but I rather take your code for it :-)
I could some threaded model. I've been thinking about header caching: We implement a cache table with fields
for every header you wish to cache. If a sysadmin adds a column for some funky X-Field he wants to cache, the
insertion code immediatly starts using the extra header field, while the retrieval code degrades gracefully if
a message is not yet in the cache. It would be nice to be able to launch a slow priority thread that gradually
starts to analyze all older messages without interfering with the imap interaction.
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.
GLib's aim is to be portable and gracefully degrading. But pthreads does have a serious industrial grade
image. And the lack of priorities in gthreads is kind of disappointing.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
