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: Unreliable flock

On Apr 4, 2016, at 10:51 AM, Andrey Repin <> wrote:
>> BSD file locks created via flock are only propagated to the direct parent
> that's a showstopper. In short, it makes the function literally useless.

Nonsense.  Thatâs only true if âliterallyâ every program that uses BSD locks creates grandchildren that also need to use those same locks.

I know of one program for certain that uses BSD locks under Cygwin that doesnât create grandchildren, and its extensive test suite passed with Cygwin/BSD locks the last time I ran it.

> Why they aren't real locks? What's use for "advisory locksâ?

âRealâ locks are generally not what you want when running purely Unix/Linux software under Cygwin, because thatâs not what you get by default on Linux or Unix.  You have to go out of your way to get mandatory locking on POSIX systems, as a rule.

Mandatory locks arenât purely positive.  Theyâre the single biggest reason Windows still needs a reboot for many kinds of upgrades, while Linux generally only has to be rebooted for kernel or glibc upgrades, and the latter is, strictly speaking, optional.

> "I think I may
> have a use for this file, but you are free to delete it, if you wishâ ?

Among cooperating processes, thatâs perfectly fine.

Consider SQLite.  On a system where SQLite decides to use some form of advisory locking, the primary risk of damage isnât rm or dd, itâs another copy of SQLite coming along and writing to the DB while the first is in the middle of a transaction,.

Problem reports:
Unsubscribe info:

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