This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]