Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates
 64.233.184.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=AHd0kQxsBwxszZprb6BWt3DYW4mZ3Kx4dHIcAZI6PnPZwsAQqPYbeHjXiKQVxcWcrQM/98452dZrn2JOO7+hwRfY2El33dPX2wuN5QkxHvo5+VbDVqInpaqy8YuBx8tlVluD9oO/ExpDLpKTM0B2oEBHvfw2AESzXlwxSuAadL0=
Message-ID: <7edfeeef0601211930u786f00dapc58eb17ead7eeb29@mail.gmail.com>
Date: Sat, 21 Jan 2006 19:30:52 -0800
From: Garrett Rooney <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: APR Developer List <dev@apr.apache.org>
Subject: Threads, Locks, Seeks, and Unix
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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