Subject: Re: managing multiples MAILSTREAMS at same time

From: Raul Dias <[email-masked]>
Date: Tue, 13 Nov 2001 15:42:34 -0300

>On Tue, 13 Nov 2001 09:59:02 -0300, Raul Dias wrote:
>> Can I safely work with more than one mailstream at a time?
>
>Yes.  Many applications do that.
>
>> what are the issues related to this?
>
>No special issues.
>
>> Most callbacks (mm_flags, mm_status, mm_searched, mm_exists, mm_expunged,
>> mm_list, mm_lsub, mm_notify, mm_critical, mm_no_critical, mm_diskerror)
>> returns the mailstream used that causes it.
>> Is it safe to work with another mailstream during this callbacks?
>
>The question is, "why do you want to do this?"

I will be using c-client in a event loop to proccess a few mailboxes concurrently.
In some cases c-client might block for a a few seconds and a callback would
be a good place (or not) to check for pending events on the event loop
(e.g. I/O events).
So I need to know where I would be stepping on.

>
>A callback should be a very small function that does *NOT* recurse back into
>the c-client library.  So you should not call any mail_xxx() functions from a
>callback function.  In fact, it is dangerous to do so, even if it's a
>different stream (so it won't trigger the "lock when already locked" bugtrap).

that's exactly what I needed to know.

>
>> Some others callbacks (mm_log, mm_dlog, mm_login, mm_fatal) does not return
>> the mailstream.
>> Some situations does not makes sense to return the mailstream, but others do
>> (e.g. some mm_log() calls).
>> Shouldn't a mailstream be passed with this callbacks (NIL if it doesn't
>> makes sense) ?
>
>It possibly could sense for mm_log() and mm_dlog(), but there is 14 years of
>history that doesn't have them.  In addition, there would be many calls which
>would have a NIL stream.  In general, if an event is something that the
>application needs to know the stream, mm_notify() is called rather than
>mm_log().

The 14 years are louder.  A few flags can take care of mm_log().

Thanks for the info,

Raul Dias

---

From: Mark Crispin <[email-masked]>
Date: Tue, 13 Nov 2001 10:47:31 -0800 (PST)

> So I need to know where I would be stepping on.

Event loop issues are always troublesome.

The usual technique is to have a miniature event loop, much as you propose.
An example is how blocking is implemented in the TCP code for the MacOS port.

However, I don't think that you'll get much help from callbacks for blocking
events in c-client.  It is much more usual to get a callback when c-client is
not blocking; that is, when you get a callback it's quite likely that the main
function return from c-client will happen immediately afterwards.

The main exception would be a search, through a very large mailbox, that has
to parse RFC822/MIME structure since it hasn't already been done.  In that
case, you may be PARSE mm_notify() events from bogus RFC822/MIME.