Jean-Claude Wippler wrote:
> If you want to lock with a separate lock file ("dotlocking", see below),
> then there is no problem, although there can be a race condition (which,
> on a network, slow link, etc, can be a serious issue). In this case,
> using the Tcl-only locking approach is perhaps most suitable.
>
> If you want to use fcntl/lockf/flock system calls, then locking may or
> may not work - AFAIK, some platform combinations simply don't lock,
> while some others can cause the underlying faulty lock daemon to hang.
> Here's an excerpt on a note I found through Alta Vista:
>
> ========================================================================
> A brief overview regarding locking methods would be:
> dotlocking (*.lock) If you want to lock "testfile", try and
> create a *new* "testfile.lock" in the same
> directory. Repeat (with ample sleep) until
> this succeeds. To unlock, simply remove the
> file. This method is supported by almost
> all configurations.
> fcntl() (POSIX) Usually implemented over the lockd program
> (thus NFS aware).
> lockf() (SysV) Usually implemented over fcntl().
> flock() (BSD) On SunOS this only locks locally, on other
> systems it might use the lockd.
> ========================================================================
>
> It's by Stephen van den Berg, Procmail's author:
> http://members.xoom.com/procmail/best-of-procmail-list/3
>
> Another place to look for tips is Mailman (Python, http://www.list.org),
> see the file mailman-1.0rc1/Mailman/flock.py - which says:
>
> """Portable (?) file locking with timeouts.
> This code should work with all versions of NFS.
> The algorithm was suggested by the GNU/Linux open() man page. Make
> sure no malicious people have access to link() to the lock file.
> """
>
> It sure would be nice if there were a package which jumps through all
> known hoops to implement locking, on most Unix'es, Windows, Mac, etc.
> IMHO, this is an example of where the split between Tcl, Python, Perl
> and others is hampering the generation of a general package.
>
> -- Jean-Claude
Tk is already accessible to both Python and Perl, though I don't know how
easy it is to use it? Perhaps there should be a general discussion on how
to
share extensions between the three platforms. I only know the TCL mechanism
well at the momment, but I got the general impression that it was the best.
Perhaps, that's just because Perl & Python are less advocated on
comp.lang.tcl
than tcl is :-). Is anyone going to raise this topic at the forthcoming
scripting conference (which I believe originally centred around perl)? What
would
we need for a generalised extension architecture? I'm sure it would involve
more
than just swapping Tcl_CreateCommand for Perl_CreateCommand or whatever
(especially as we are now encouraged to use Tcl_Obj's in our interfaces.
A general solution is to have in each language a routine allowing cross
language
calls to be made e.g. in perl have an InvokeTCLCommand function and in
TCL an InvokePerlCommand function. Of course some extensions would
require access to the languages interpreter and others wouldn't. This
solution
would also come at the cost of some efficiency. Would people be prepared to
pay that cost? Any thoughts?
Regards,
Bruce A.
> If you want to lock with a separate lock file ("dotlocking", see below),
> then there is no problem, although there can be a race condition (which,
> on a network, slow link, etc, can be a serious issue). In this case,
> using the Tcl-only locking approach is perhaps most suitable.
>
> If you want to use fcntl/lockf/flock system calls, then locking may or
> may not work - AFAIK, some platform combinations simply don't lock,
> while some others can cause the underlying faulty lock daemon to hang.
> Here's an excerpt on a note I found through Alta Vista:
>
> ========================================================================
> A brief overview regarding locking methods would be:
> dotlocking (*.lock) If you want to lock "testfile", try and
> create a *new* "testfile.lock" in the same
> directory. Repeat (with ample sleep) until
> this succeeds. To unlock, simply remove the
> file. This method is supported by almost
> all configurations.
> fcntl() (POSIX) Usually implemented over the lockd program
> (thus NFS aware).
> lockf() (SysV) Usually implemented over fcntl().
> flock() (BSD) On SunOS this only locks locally, on other
> systems it might use the lockd.
> ========================================================================
>
> It's by Stephen van den Berg, Procmail's author:
> http://members.xoom.com/procmail/best-of-procmail-list/3
>
> Another place to look for tips is Mailman (Python, http://www.list.org),
> see the file mailman-1.0rc1/Mailman/flock.py - which says:
>
> """Portable (?) file locking with timeouts.
> This code should work with all versions of NFS.
> The algorithm was suggested by the GNU/Linux open() man page. Make
> sure no malicious people have access to link() to the lock file.
> """
>
> It sure would be nice if there were a package which jumps through all
> known hoops to implement locking, on most Unix'es, Windows, Mac, etc.
> IMHO, this is an example of where the split between Tcl, Python, Perl
> and others is hampering the generation of a general package.
>
> -- Jean-Claude
Tk is already accessible to both Python and Perl, though I don't know how
easy it is to use it? Perhaps there should be a general discussion on how
to
share extensions between the three platforms. I only know the TCL mechanism
well at the momment, but I got the general impression that it was the best.
Perhaps, that's just because Perl & Python are less advocated on
comp.lang.tcl
than tcl is :-). Is anyone going to raise this topic at the forthcoming
scripting conference (which I believe originally centred around perl)? What
would
we need for a generalised extension architecture? I'm sure it would involve
more
than just swapping Tcl_CreateCommand for Perl_CreateCommand or whatever
(especially as we are now encouraged to use Tcl_Obj's in our interfaces.
A general solution is to have in each language a routine allowing cross
language
calls to be made e.g. in perl have an InvokeTCLCommand function and in
TCL an InvokePerlCommand function. Of course some extensions would
require access to the languages interpreter and others wouldn't. This
solution
would also come at the cost of some efficiency. Would people be prepared to
pay that cost? Any thoughts?
Regards,
Bruce A.