On Tue, Feb 6, 2007, Leif Jackson <[EMAIL PROTECTED]> said: > On Tue, February 6, 2007 3:35 pm, Aaron Stone wrote: >> On Tue, Feb 6, 2007, Aaron Stone <[EMAIL PROTECTED]> said:
>>> eliminated the need for a thread pool library and for any super >> >> Sorry, I *do* need a thread pool library -- I'm going to use Glib's. I >> won't need a database pool library; each thread will own its own database >> handle directly. > > If you do use a thread pool then the threads in the pool will have to know > how to handle both pop and imap, as GLib's thread pool is a little > limited. I have had some issue with it as well in how it spreads work over > the pool and some other things, my advise test a LOT before you commit to > glib's thread pool. Pthread portablity might be the only issue to writing > your own but they are not hard to do. We can do a multiprotocol server, or continue to have several binaries that each have code for a single service. I don't feel strongly either way. If performance of Glib's thread pool is below par, we can push them to make it faster. I'd prefer to continue to leverage other people's API's wherever possible. Any experience you can share will be greatly appreciated! Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
