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.
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. Aaron ""Wolfram A. Kraushaar"" <[EMAIL PROTECTED]> said: > Would be nice if this gets configurable like with > the mpm modules in apache 2, so systems without pthreads > are also supported. > > just my 2 cent > Wolfram > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Leif Jackson >> Sent: Montag, 20. September 2004 19:46 >> To: DBMAIL Developers Mailinglist >> Subject: Re: [Dbmail-dev] refactoring plans for 2.1 >> >> Along with this I would like to start a discussion on the >> possiblity for >> doing away with the fork code and going to a pthread model >> with a thread >> pool, I have already starting some proof of concept code on >> my own, but >> with the performance on threads in linux 2.6.8 and the performance of >> threads on my Sun boxes this would give DBmail a leap ahead. >> Let me know >> the thoughts ...etc from everyone on if you guys think it >> would make any >> since to switch to a threading pooled model. >> >> Thanks, >> Leif >> > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
