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.