[racket] flock() stops racket-5.1.1 build on Solaris x86

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.brown at 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.