From: ahoward <ahoward@...>
Date: 2003-01-27T09:16:31+09:00
Subject: Re: solaris porting problem -- flock failure?

On Mon, 27 Jan 2003, Joel VanderWerf wrote:

> Interesting. I checked again using two irb sessions that waiting for a
> lock does block all ruby threads. Also, I ran my solaris-bug.rb without
> the polling code (the ugly hack), instead just calling #flock. I
> expected deadlock. Over several runs, I've seen two kinds of results:
>
> 1. solaris-bug.rb:43:in `flock': Interrupted system call -
>     "/tmp/test-file-lock.dat" (Errno::EINTR)
>
> 2. solaris-bug.rb:128:in `load': marshal data too short (ArgumentError)
>
> The latter looks like the same collision problem as usual. Could #1 be a
> result of deadlock, which I would expect to happen eventually?

according to the fcntl man page this _might_ be the result of catching a
signal during the period that the process was blocked waiting for the lock,
what signal that could be i do not know....

> Anyway, the fact the #2 happens (no pun intended) at all suggests that
> polling isn't really the cause of the problem, and blocking the whole
> process doesn't prevent the collision.

hmmm.  i truely have no idea why it would be but the

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

line in file.c which prevents the rb_thread_flock method from getting defined
makes me wonder.  can anyone shed light on this?  i did some searching in this
group and found no mention of it...

> It's particularly confusing to me because ruby threads all run in the
> same native thread, so I expected to be insulated from any
> multithreading problems with locks or with anything else at the system
> level, as long as I was careful to manage concurrency among my threads
> (keep reader counters and use LOCK_NB, use Thread.critical, etc.).

maybe the flock implementation uses some sort of process level global state
which gets copied when forking, but which gets clobbered by competing
threads...  i realize this is OT but i'd really like to know now.

> The test program runs perfectly with thread_count == 1 (that's ruby threads,
> not native threads, and it doesn't count the "supervisor thread", only the
> "workers", so there are actually still 2 threads). So I have trouble
> believing that the underlying flock implementation (in ruby source or in the
> depths of solaris) is bad. It seems to me that as long as ruby's threading
> code is correct, and I use appropriate threading constructs correctly, this
> should all work.

do some searching on google and i don't think you'll have so much trouble
believing an flock implementation could be bad.  ;-)  last week i was amazed
to learn that a multi-threaded C program i had written could not use
fprintf/fflush to force writes, and that i had to resort to
write/read/flush/sync to do this...

-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
 ====================================