[dovecot] Re: inetd/xinetd/tcpserver support

[Timo Sirainen]

On Thu, 2003-03-20 at 14:51, GARY GENDEL wrote:
> > iirc correctly cras implemented resuing of the already spawned
> > processes. maybe a reason.

No, I don't reuse processes. They could be reused within same UID, but
I'm not sure if it's good idea. At least if the UID is used by multiple
users, something sensitive could be left in process memory space from
previous user and that's not really good.

I've actually been thinking that I could make imap process completely
non-blocking which would allow using one process for multiple IMAP
connections for same user. The problem cases are mostly just APPEND
which blocks for input from user, and the commands which return a lot of
data and block on output. After fixing those, there's still the problem
that at least SEARCH could block because it's so slow. Maybe have two
processes, one handling slow/large queries, other handling quick
queries.

Well, there's still the annoying problem that by making the output
non-blocking, I'd have to be constantly calling poll() to see when I can
write more data. That's a lot of useless syscalls compared to the
current blocking model.

> tcpserver has been used in the high-performance mail system, Qmail.  It 
> really doesn't suffer as high an overhead as you think.  Three processes 
> are not spawned, instead each one is replaced by the next in the same 
> process space (using execv or execvp).  tcpserver either rejects the 
> connection (based upon connecting IP rules), or adds specified variables 
> to the environment and execs the next program in the chain.  imapauth 
> negotiates login, fails or execs imap.  This kind of exec chaining has 
> shown to be really efficient on unix/linux platforms.

It also has the problem that it has to run as root until user has
authenticated.

Dovecot can also be setup to use a single process to handle multiple
login connections. That means only a single fork+exec per connection,
and still never parsing user input as root.