Re: [MacPerl] CGI Threading & File Locking

[Joel Rees <joel_rees@sannet.ne.jp>]

>On Sun, 20 Feb 2000 19:20:24 -0800 (PST), Michael Geffon wrote:

I've got to learn how to make these quote tags, I guess. Perl called from 
BBEDIT (or VI)? AppleScript? Eudora? But that's a side issue.

>
>>I've been struggling to determine how people handle locking without an
>>implementation of flock() on the Mac, but then it hit me that if the
>>requests are processed sequentially and not concurrently this becomes a 
>non-issue.

The implementation of flock(), according to p. 195 of the llama (2ed), 
"varies wildly between systems," and is only guaranteed to be at least a 
semaphore locking mechanism that is not binding to programs that do not 
refer to it. 

I looked in the archives for this, and somebody said there is a FAQ that 
says that flock() is not available on the Mac. I looked in the on-line 
FAQs and the pods and find no such FAQ. So I read in the perl faq pod 
about files and it says in there that flock() should be the UNIX flock(), 
or call fcntl() if flock() is not available, or call lockf() if fcntl() 
is not available. It may even use a different form of native locking. If 
none of the above is available, it causes a fatal (compile time?) error.

I don't see any specific information that requires me to understand that 
flock() should not work on MacPerl.


>>
>>Even if I don't have to worry about it in this case, how _do_ I lock a
>>file under the MacOS should the need arise? There was some discussion on
>>the list archives about it, but I didn't see a clear answer. Is there an
>>accepted best practice for exclusive file locking on the Mac?
>
>Well, open a file with write permission. If the file is already open,
>this will fail. So:
>
> - There is a OS imposed (implicit) file locking mechanism, as soon as
>you want to write to a file
>
> - In this case, open() will fail. This is completely different from the
>situation under Unix.
>
>You don't need an explicit flock(), but you need to check if the file
>open failed, and if so, why. If it is because the file was "busy" (in my
>tests, $! said "invalid argument"), try again later, after some delay.
>(sleep()?)

I have the idea this can be done in C. Is there some specific reason, 
that we should not take the latitude allowed in using native locking 
mechanisms, bury the busy check in a mutual exclusion construct in 
C/assembler, and make our own flock() library call? If our library owns 
the semaphor variables, I don't think we'd need to worry about whether 
external bus masters honor the locked read/write cycle. The system's 
implicit locking against multiple opens for write would help us at least 
meet the spirit of the requirement that the call be a system call. Maybe 
we wouldn't even need to implement an actual semaphore.

Joel
http://www.page.sannet.ne.jp/joel_rees

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org