Threads, Locks, Seeks, and Unix

[Garrett Rooney <ro...@electricjellyfish.net>]

I was looking at a patch that was recently posted to fix some behavior
of files opened with APR_FOPEN_XTHREAD under windows.  Out of
curiosity, I decided to see how similar code worked under unix, and
now I'm a bit confused.

The unix file_io code creates a lock in various situations, and then a
fair amount of its code makes use of it to synchronize access to the
file across multiple threads.  It's used in buffer.c, filedup.c,
open.c, pipe.c, and readwrite.c, but it never gets looked at at all in
seek.c, and that seems sketchy.  seek.c is full of places where the
underlying file descriptor has some kind of function called on it, and
then the bookkeeping fields in the file object are updated.  It seems
like those really need to be kept in sync, and to do that with an
XTHREAD file the lock would need to be involved...

Am I out of my mind here, or is this kind of broken?

-garrett

Re: Threads, Locks, Seeks, and Unix

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Garrett Rooney wrote:
> I was looking at a patch that was recently posted to fix some behavior
> of files opened with APR_FOPEN_XTHREAD under windows.  Out of
> curiosity, I decided to see how similar code worked under unix, and
> now I'm a bit confused.
> 
> The unix file_io code creates a lock in various situations, and then a
> fair amount of its code makes use of it to synchronize access to the
> file across multiple threads.  It's used in buffer.c, filedup.c,
> open.c, pipe.c, and readwrite.c, but it never gets looked at at all in
> seek.c, and that seems sketchy.  seek.c is full of places where the
> underlying file descriptor has some kind of function called on it, and
> then the bookkeeping fields in the file object are updated.  It seems
> like those really need to be kept in sync, and to do that with an
> XTHREAD file the lock would need to be involved...
> 
> Am I out of my mind here, or is this kind of broken?

No, the authors of some of the code such as seek() probably didn't pay
attention to it, since the author wasn't testing it.

An abusive APR_FOPEN_XTHREAD stress test seems sort of appropriate here.

Bill