bug-mailutils
[Top][All Lists]
Advanced

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

What kind of reentrancy is mailutils supposed to provide?


From: Sam Roberts
Subject: What kind of reentrancy is mailutils supposed to provide?
Date: Sat, 26 Jan 2002 09:45:26 -0500
User-agent: Mutt/1.3.16i

Bonjour mes amis!

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?

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.

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)



reply via email to

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