On Wed, Aug 01, 2001 at 09:54:41AM +0200, Henning Brauer wrote:
> This approach has many advantages as you could easily find out through
> reading the qmail list archives.
What advantages? I haven't read the list, but can't immediately see any
advantages.
> > > I guess Courier is the next big thing in open MTAs.
>
> I beg to differ.
Time will tell. Qmail hasn't been updated by Dan in how many years?
> Nonsense. qmail-ldap is very good scalable. There are a few things that
> could be done more effective (also applies to stock qmail); mostly queue
> management issues. qmail-remote is no bottleneck, qmail-queue is sometimes.
> Reduce queue i/o bandwidth is a major target, Dan has interesting ideas
> published with his zeroseek package. In general take a look at
> http://cr.yp.to/qmail/future.html.
>
> > > I wish to see a good multi-threaded open MTA in the future.
> > > Is it too much to ask for?
> > *SHRUG* I don't have any problems with qmail-ldap's model. It maybe fork
> > heavy, depending on how you look at it, but no more then sendmail, if that
> > much.
>
> Since when forking is bad? If forking is bad, apache is bad, too. Forking is
> required for a clean design like qmail(-ldap). Fork() is awfully slow on
> Solaris, but solaris is broken in many other aspects to. It's sun's fault,
> not qmails.
I didn't say fork()ing is bad. Threading is just easier on the kernel
and VM. A process requires much more kernel and memory resources than
does a thread.
New version of Apache (currently in beta) is multi-threaded if
you didn't know. Not only that, it has several choices of threading modules
sysadmin can choose for the 2.0.x Apache (including the cool State
Threads library).
