Re: The sad state of locking -> it almost works

[xystrus]

On Fri, Apr 12, 2002 at 04:30:34PM +0300, Sergey Poznyakoff wrote:
> > Sam writes in the previous message in the thread that you can't switch
> > from a dotlock to a kernel lock and expect it to work.  I think it
> > makes sense it wouldn't; I'm not sure why it would make sense to
> > switch lock types in the middle of some operation.
> 
> It wasn't actually a switch to another locking method. It was simply an
> heuristic aimed to avoid trying to create a file in a non-writable
> directory: an operation that would fail anyway.

I see... :)

> > The UW-IMAP documentation talks about locking at length, and you can
> > read what they have to say here:
> > 
> >   http://www.washington.edu/imap/documentation/locking.txt.html
> 
> Thanks for the link. This is really very useful information. 

I'm always a fan of borrowing insight from those who've already
learned it the hard way...  ;-)

> it confirms my viewpoint about kernel locking, to wit (page 14 of the
> document):
[SNIP]
> Opinions?

A couple of points:

 - if you're going to be dot-locking (exclusive lock) anyway, there's
   really no point in bothering with a shared lock.  And then, you
   might as well also always open the mail store O_RDWR (and always
   take a write lock), so you don't have to worry about losing your
   lock if you need to switch from shared to exclusive.

 - flock() is not supported by POSIX, and except for maybe recent
   SVr4-based platforms, System V based systems don't have flock AFAIK
   (and W.R. Stevens seems to agree... Advanced Programming in the
   Unix Environment, pg 367).

 - To the best of my knowledge, flock locking DOES NOT WORK over NFS
   on any platform.

 - fcntl() is supported by all the specs, and has a fair shot of
   working on most platforms, even over NFS.

FWIW, what I've been up to is more-or-less re-implementing something
along the lines of the API of the original libmailbox.  There are a
couple of reasons I've been doing this.  The foremost reason is purely
as an academic exercise.  I have no experience working on anything
but small projects, and I thought it would be good to do that.
Another is (as I mentioned a while back) I want to mess with MMIO vs.
read/write and compare performance and resource utilization.
Mailutils has a lot of nice features but it's kinda clunky and
overkill for what I want to do (IMO).  

That leads to the next reason which is I was hoping mailutils would be
what I originally understood it was going to be...  a small, tight API
for providing access at the physical layer to mail folders.  I don't
remember who the original author of Gnu pop3d was (Alain maybe?), just
that he was really bitter about not getting into UW, and wanted to
show them up...  :)  

Anyway, you guys are doing some really cool things with mailutils, and
I like the idea of url access especially.  But I'd rather see that
implemented in a different layer, on top of the physical access layer.
It seems to me mailbox kinda tries to handle everything all at once,
and I'd rather break everything down into layers -- physical layer,
application layer (like dealing with MIME and e-mail addresses and
lions and tigers and)...  

So, that's sorta what I'm doing.  ;-)  The locking scheme I
implemented first creates a dot lock, then an advisory (fcntl) write
lock.  The file must already be opened for writing, in that case.
I've already got the locking more or less hammered out (for my needs,
anyway), though I haven't really given any regard to signal
handling/blocking yet...  There are plenty of other examples out there
for you to look at, written by people who have a lot more programming
experience than I do, but if you want to see my code, I'd be happy to
share it.

Xy