From: ahoward <ahoward@...>
Date: 2003-01-27T03:34:26+09:00
Subject: Re: solaris porting problem -- flock failure?

On Sun, 26 Jan 2003, Joel VanderWerf wrote:

from http://path.berkeley.edu/~vjoel/ruby/solaris-bug.rb

# ugly hack because waiting for a lock in a Ruby thread blocks the process


this is the problem i think.  if you look at the file.c implementation of
rb_file_flock you'll notice that it _used to_ do something very similar at the
C level - but that this has been _removed_

file.c:1531 #if defined(EWOULDBLOCK) && 0
....

which you've essentially re-implemented in ruby.

i'm guessing someone smarter than us realized this was not safe.  thus, it
appears that the correct behavior for flock is block the entire process and
that threads should not be using flock at all.  i do not understand the exact
reason for this, but searching google for flock/fcntl/thread will bring up a
plethora of problems.  i think you can be farily certain that the behavior of
flock from inside a threaded program will be ill-defined across OSs.

as to a fix : keeping in mind that file locks are only (usually) advisory you
don't really buy anything using flock over a mutex since any other process can
chose to clobber the file anyhow - the lock will not prevent this.  this is
troublesome since you also want to fork...  the only way i can think of doing
this is to have each thread ask it's parent process to lock the file in it's
stead (in a critical section), rather than attempting to do so itsef. even
this might not be safe and you might have to resort to some sort of IPC to
ensure single writer semantics.  the sysvipc module from the raa seems to be
unreachable right now.  does anyone have a copy?

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================