mailutils/locker.c

[Alain Magloire]

Bonjour

> I have followed the basic guidelines we have discussed, except
> that I have not implemented locker_set_??? functions. Instead,
> I have modified locker.c to implement reference count.

Yes, you probably made the right decision not to implement the
locker_set_?? functions.   Most of the objects in the library
mailbox_t, message_t, stream_t etc ... provides _set_xx() functions
because, you can have different implementations for them.  For example
mailbox_t, POP, IMAP.  But locker_t probably does not need the heavy
artillery for now.

> The struct _locker is now:
> 
> struct _locker
> {
>   int fd;
>   int refcnt;
>   char *fname;
>   int flags;
> };
> 
> 
> The refcnt member gets incremented each time locker_lock is called and
> decremented each time locker_unlock is called. Actual locking is
> performed only if refcnt == 0 on entry to locker_lock. Similarly,
> unlocking is performed only when refcnt gets decremented to 0 by
> locker_unlock.

Ok, patch in, thanks.
The only change was LOCK_EXPIRE_TIME rename to
MU_LOCKER_EXPIRE_TIME, since now it is in the global namespace
(include/mailutils/locker.h).  All the macros when exported have MU_ prefix.

> Also I have added basic support for NFS-secure locking.
> 

Ok, I'll try to complete later(low priority).

> The program tries to touch its lock each LOCK_EXPIRE_TIME/2 seconds.
> In order to make it possible I had to move LOCK_EXPIRE_TIME declaration
> to header file locker.h. (btw: Maybe we should made it configurable?)
> Another approach would be to touch lockfile after receiving
> a command from the user, but it seems to have considerable drawbacks:
> on slow links retrieving a letter could take considerable time, which
> is bigger that LOCK_EXPIRE_TIME. Then, while one session is still
> retrieving the message, another user could open the same mailbox,
> the program would decide that it has expired and destroy it. Thus,
> all modifications done by the first session would be lost. So, I have
> decided to touch the lockfile in regular intervals. What do you
> think?
> 
> The select() or read() calls in pop3d_readline() can now be
> interrupted by SIGALRM, so appropriate handling for EINTR is
> added to the function.

This is a problem. In the case of the read() and accept() we can
control it by checking EINTR.  But if the alarm goes off when doing
a write, in the middle of RETR or TOP, we have a situation.

To send the data we use stdio fprintf (ofile, ..).  Stdio does not provide
a clean way to recuperate or to know about an interruption.  Meaning
deep inside stdio calls the write() will fail and in theory the
error will propagate up and fprintf () will return a smaller number
then ask and its up to us to call ferror().  In the end, we'll have
to check for every single fprintf (ofile, ...) calls and contraily
to the read()/accept() which are at one place fprintf() is everywhere No fun.

So I left out this portion of the patch.

> Just in case, while  in transaction state, a consistency check is
> performed after receiving each command, so if the mailbox gets
> updated by any program that does not honour the lock, the modifications
> will not be flushed. (Addition of newly arrived messages is handled
> correctly, though).

I prefer the old way; by checking for the size, instead of checking for
the message count like you propose.

--
alain