Subject: managing multiples MAILSTREAMS at same time

From: Raul Dias <[email-masked]>
Date: Tue, 13 Nov 2001 09:59:02 -0300

Hi,

I want to know what ae the current status of c-client regarding MAILSTREAMS in a 
single-threaded/event based application.

Can I safely work with more than one mailstream at a time?  what are the issues related to
this?

In the docs/internal.txt there is an alert regarding the use of MAILSTREAMS in a callback function.

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?

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) ?

How different is internal.txt from the actual API? what (files) should I look to get an update 
view of the API?

Regards,

Raul Dias

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

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

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.

The question is, "why do you want to do this?"

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).

> Some situations does not makes sense to return the mailstream, but others do
> (e.g. some mm_log() calls).

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().

There is no fully-formed stream when mm_login() is called.  The NETMBX struct
argument contains everything that is currently available for the application.

The only thing that an application should do with mm_fatal() is close any
local files.  It should not try to do anything at all with mail streams.  If
mm_fatal() is called, things are badly messed up, and an expert needs to debug
the core dump.  You do not want to distort things any worse by doing anything
that isn't strictly necessary to the purpose of crashing.  The core dump will
have all the mailstream, etc. information that one might need.

> How different is internal.txt from the actual API? what (files) should I
> look to get an update view of the API?

The API has over 5 years of development, and there have been significant
changes.  Internal.txt has a lot of good information, but it's like using an
old BSD 4.3 manual to guide you on Linux.

At the very least, you need to look at mail.h, which defines the most
important interfaces.  Also smtp.h, misc.h, and rfc822.h.