This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: F_ULOCK, F_LOCK, F_TLOCK, F_TEST missing in unistd.h
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: <cygwin at cygwin dot com>
- Date: Fri, 27 Aug 2004 21:27:16 -0500
- Subject: RE: F_ULOCK, F_LOCK, F_TLOCK, F_TEST missing in unistd.h
> On Aug 26 22:48, Gary R. Van Sickle wrote:
> > Well, I just did my 2 minute due diligence and looked up the
> > difference between advisory and mandatory file locking. Did I read
> > right? Does advisory locking actually in no way prevent
> write access to the "locked"
> > file unless all the interested processes also explicitly
> use lockf() etc?
>
> Yes.
>
Wow. Is this acually a useful thing, or just an unseemly holdover from the
bad-old-days?
> > If so (and I must be missing something there), couldn't this be
> > implemented in Windows simply as named mutexes, with the
> names being
> > some suitably-chosen derivative of the file name? You
> wouldn't even
> > need to do any explicit sharing between Cygwin processes then.
>
> Keep in mind that it's not per-file locking but record
> locking. So you'd need mutex names which reflect the locked
> region in the file as well. But then you'd need one mutex
> per locked record. How do you find overlapping regions hold
> by other processes? To make it worse, flock(2) locks are
> preserved across forks, so both processes hold the lock together.
Hmmm. Well, is there some reason you couldn't just use LockFile{Ex} et al?
Any apps that are expecting to simultaneously write to the same file without
"real" locking are busted anyway, aren't they?
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/