bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What kind of reentrancy is mailutils supposed to provide?


From: Alain Magloire
Subject: Re: What kind of reentrancy is mailutils supposed to provide?
Date: Sun, 27 Jan 2002 11:41:24 -0500 (EST)

> 
> Bonjour mes amis!

Hello frenchie,

> 
> There is code to support protection of critical sections using
> monitors, but isn't general enough, for example, to allow two
> mailboxes opened by different threads to be used safely if they
> are both imap, same user, same host, and same port. They can
> trash each other's commands (f_imap->seq isn't protected, for
> example).
> 
> The internal states seems an attempt to allow continuation of
> an operation at the same point as where a previous attempt had
> failed with EAGAIN. But there are holes there, as well. For
> example, imap_append_message() won't work if imap_append_message0()
> returns EAGAIN.
> 
> What is the intention of this code, do I misunderstand the point,
> or is it just not completely finished yet?

A little of bit of this and a little bit of that.

There are two issues involve.
- Async I/O
- thread-safe(cancel-safe)

Async I/O(when the fd is non-blocking) is/was very very
hard to get correctly and in some cases, I give up.  It will
make the code simply too ugly(i.e. to save the entire state
of the connection, when returning EAGAIN).

For example, If you get rid of Async I/O, the POP3 code is deadly simple.

IMAP4 is a problem,  this is one of the reason, I wanted
to start with a clean sheet ... but free time became a luxury.


Then thread-safe and thread-cancel-safe, and many many
types of thread implementations.  Monitor was a small attempt
to come up with some porting layer(Limiting the number of
#ifdef's ...).
Maybe it would be easier to just support PThreads.

> I'm trying to open an imap mailbox and append to it. I need
> mailbox_open() to behave like the other opens in order to
> do this:
>   if the mailbox exists return 0
>   else
>     if CREAT is set, create it
>     else return ENOENT
> 
> I've done this by listing the mailboxes to check existence, and
> creating only if necessary (previously no check was done for
> existence, but if CREAT was set it would try and create it, failing
> if it existed, this totally hosed me: open without O_CREAT
> always worked, and open O_CREAT usually failed!).
> 
> I'm trying to make sure it works in the EAGAIN case, but I'm a
> little dubious about how well it is going to work. I might
> check in what i have now (it works with blocking IO), and
> fix it later.

Ok, time is up, gotta go, later.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]