[Top][All Lists]
[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!)
- What kind of reentrancy is mailutils supposed to provide?,
Sam Roberts <=