[Gambas-user] Changes in LINK

[Benoit Minisini]

On Sunday 29 October 2006 00:54, Christopher Brian Jack wrote:
> On Sat, 28 Oct 2006, Benoit Minisini wrote:
> > You have the LOCK and UNLOCK keyword for locking/unlocking a file opened
> > for writing.
> >
> > Maybe I should rewrite them so that they work on a path and not on a
> > file. This will be easier to use: you choose a path file that will work
> > as a lock, and you use LOCK and UNLOCK on it.
>
> There are times where locking is desirable for readers as well as writers
> such as when access to one part of a file is an index to where other data
> should be written.  If a race condition develops between two concurrent
> accessors on the file and one changes the index between the time the first
> app does it's read then reopens for write+lock there will definately be
> file inconsistencies and a whole new insect kingdom of bugs--that the
> programmer didn't even know existed--creeping in.
>
> Hopefully locks can be requested when the file is open FOR BOTH?
>

Actually the goal of LOCK and UNLOCK is not locking files (funny, isn't it?). 
It's a way for implementing a system-wide critical code section by using a 
file as a lock. LOCK/UNLOCK will ensure that there is only one process that 
run a piece of code at a time.

Real file locking is a problem, as it depends on the underlying O.S., the kind 
of locks supported by the filesystem where the file to lock is located, if 
the file system is on a network, which system call you use, if the file is 
buffered...

Look at 'man fcntl', 'man flock' and 'man lockf'. It is a real mess!

Regards,

-- 
Benoit Minisini