Subject: Re: A note on multiprocess IMAP server

From: "Alex Shvedov" <[email-masked]>
Date: Thu, 4 Mar 1999 19:44:16 -0500

>Huh?  This statement makes no sense at all.

>mm_critical() is your own routine, and it is called with the MAILSTREAM of
the
>stream which went critical.  That gives you everything that you need to do
>what you want, including implementing a lock if that's what's necessary.

I said explicitly: FUI, which stands for "for your information".
It's not a bug at all.
It's an advice to developers who for some (external to IMAP per se) reason
are bound to fork.

Normally one wants just to copy imapd.c, mail_link some new driver there and
live happily afterwards; that's what I did and that's why I decided to send
this comment.

Since You provided these mm_(no)critical as wrappers for
critical=TRUE/FALSE, forked variant is not a problem at all.

P.S. Is it just my impression that the first part of Your reply contradicts
to the second one? Really, the second part actually says that I am right,
while a statement that has no sense can not be neither right nor wrong.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 4 Mar 1999 17:33:01 -0800 (PST)

> critical=TRUE/FALSE, forked variant is not a problem at all.

This also makes no sense.

As distributed, imapd handles a single IMAP session, and for the most part
does it in a single process.  IMAP's I/O for the session is via stdio.  All
drivers run in the same process.

The only thing that mm_critical() is used for is to allow a driver to tell the
main program that it is in dangerous code that should be allowed to run to
completion.  That, in turn, is used by imapd's signal handlers to determine
whether or not it should exit on a signal.

You seem to be saying that you have taken the original imapd and modified it
to run in an entirely different way.  If you do that, then it has become a
different program, and you're responsible for doing whatever has to be done to
make that program work.  That may include changing how it does command I/O, or
how it handles signals, or any number of other details.

More importantly, imapd is not c-client.