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


[snip]

> Seriously, the basic idea is not to implement lockf, but to 
> implement advisory locking.  Windows doesn't support advisory 
> locking, only mandatory locking.  So, roughly the idea is to 
> use some internal locking structure and to implement lockf, 
> flock and fcntl-locking on top of that.  All these 
> implementations are only advisory, so the whole job is to 
> keep the information ready for all Cygwin processes, and to 
> give them the expected locking behaviour as a process would 
> get on, say, GNU/Linux, but without actually locking the 
> files on Win32 level.
> 

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?

Yikes.

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.

-- 
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]