Re: imap4d - feature request :-)

[Alain Magloire]

> 
> Sam Roberts <address@hidden> writes:
> >  
> > > It is multi-process though but I wouldn't call it overkill. However, 
> > > I'd prefer something thread based which is why I want to add maildir 
> > > support to this project. 
> >  
> > What do you mean by thread based? 
> 
> Sorry, that was a bit terse wasn't it?

8-) ...

- security
  fork() allows to isolate the connection so when doing
  chdir(), setuid(), setgid()  the server is not affected.
  In a thread-server this will have to be control very carefully.
  Maybe by blocking the other threads in this critical region and
  fliping on/off the set{u,g}id();

- access to files control per thread(see setuid() above)
  number of file descriptors open maybe very limited on OS.
  So suppose you have to maintain 2/3 fd's open per connections.

- locking contentions.  Thread maybe lightweight  but if you
  do not do fine grained locking(reducing the number of locks) you
  will end up with bottlenecks loosing any advantages threads provided.

This is the tip of the Iceberg, I'm glossing over signals, accessing
mailbox relative to cwd per thread etc ..
Statistics/performance that I've seen on threaded-servers vs forking-servers
were not very good for threads under heavy loads(locking
contentions breaking down for hundreds of requests? etc ..) ... again
we have to be carefull about statistics and look cases one by one.

I can see this working well for a simple Read-Only Imap server.
And with a little organisation the locking could
be reduce to a minimum.

But for a full fledge features, heavy load, secure server ...

It would certainly be quite a challenge 8) even for POP3 this not
obvious .. well at least to me.

EOT