On 24/05/11 03:28, Matthew Flatt wrote:
At Mon, 23 May 2011 12:52:12 +0100, Tim Brown wrote:
Solaris seems to take quite a dim view of flock(); from man flock():
That's nothing compared to the dim view of F_SETLK in the BSD world.
Ooh... this sounds like it could get religious!
From a Racket implementor's perspective, the BSD side has it right.
It's not just subroutines within Racket, but different threads within a
single Racket process that might compete for a file lock; when a thread
fails to obtain a lock and closes a file, any thread in the same OS
process that held the lock immediately loses it.
Do I understand this right?
Thread 1 opens file f, gets fd1, and asserts a read lock, and obtains it
Thread 2 opens file f, gets fd2, and asserts a read lock, and obtains it
Thread 3 opens file f, gets fd3, and asserts a write lock...
fails to obtains the lock and closes fd3 in disgust; which, by what
I understand you're saying is "a thread fails to obtain a lock and
closes a file"... do threads 1 and 2 lose their locks?
I don't see an easy way around the problem. Your patch to make file
locks unsupported looks like the right one for now.
Just so I'm clear -- that's the Solaris specific patch.
Tim
--
Tim Brown <tim.br...@cityc.co.uk> | City Computing Limited |
T: +44 20 8770 2110 | City House, Sutton Park Road |
F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
