RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

["William A. Rowe, Jr." <wr...@apache.org>]

At 12:52 PM 10/25/2002, Bill Stoddard wrote:
>The point of my comment was that this is irrelevant for what I am interested
>in talking about.
>
>But since we are on the topic... APR_XTHREAD implies the file needs to be
>opened for overlapped i/o.  Files opened for overlapped i/o don't HAVE OS
>maintained file pointers. I assume (correct me if I am wrong) that
>APR_APPEND has the same semantic meaning as Unix O_APPEND.  If that
>assumption is correct, then passing in APR_XTHREAD|APR_FILE_APPEND on an apr_file_open is not correct and should be flagged as an error at file open
>time.  My inclination is to make the check at file_open time rather than in
>this code.

Nope.  APR_XTHREAD files must be readable, writeable and totally
compatible with APR_APPEND.  It's a couple of extra LOC, please add
them or post the final patch for me to massage.  These files have APR
maintained file pointers for compatibility with the API.  APR_XTHREAD
and APR_SENDFILE_ENABLE must remain semantically equivalent
to a usual file.  They simply might consume more overhead, or less,
depending on what the application is.

>Bill, passing in APR_FLOCK_SHARED fixed the problem. (hitting my forehead
>and sounding like a Homer).

You can't flock SHARED... that denies everyone (including yourself)
write access to the file.  Please review the FileLockEx docs.

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

["William A. Rowe, Jr." <wr...@apache.org>]

At 01:30 PM 10/25/2002, Bill Stoddard wrote:

>>
>> You can't flock SHARED... that denies everyone (including yourself)
>> write access to the file.  Please review the FileLockEx docs.
>>
>
>I did. APR_FLOCK_EXCLUSIVE maps to LOCKFILE_EXCLUSIVE_LOCK which locks out
>all reads and writes. APR_FLOCK_SHARED is what you are calling
>APR_FLOCK_WRITE (which does not exist) and allows multiple readers but only one writer.

Hadn't looked at this...

    flags = ((type & APR_FLOCK_NONBLOCK) ? LOCKFILE_FAIL_IMMEDIATELY : 0)
          + (((type & APR_FLOCK_TYPEMASK) == APR_FLOCK_SHARED) 
                                       ? 0 : LOCKFILE_EXCLUSIVE_LOCK);

doesn't trigger 'LOCKFILE_SHARED_LOCK' at all.  Wish we had used
the 'reader/writer' paradigm from reader writer locks :-)

Your code does end up with a 'write' lock, shared read, not a shared
read lock :-)

Bill

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

["William A. Rowe, Jr." <wr...@apache.org>]

At 01:48 PM 10/25/2002, Bill Stoddard wrote:
>> Nope.  APR_XTHREAD files must be readable, writeable and totally
>> compatible with APR_APPEND.
>
>That's not possible assuming APR_APPEND has the same semantic meaning as Unix O_APPEND.

Of course it is.  O_APPEND always appends.  We simply do the same
locking, no seek, grab the current lof and keep going as we were.

>> It's a couple of extra LOC, please add
>> them or post the final patch for me to massage.  These files have APR
>> maintained file pointers for compatibility with the API.
>
>Yes, if the file is opened with APR_BUFFERED, then APR maintains it's own
>file pointers. My patch is not touching the APR_BUFFERED path.

The pointer filePtr is also used throughout for APR_XTHREAD...
just look at apr/file_io/win32/seek.c.  Simply use apr_file_seek after
locking in the Overlapped case, with APR_END, 0 as your args.

Bill

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

[Bill Stoddard <bi...@wstoddard.com>]

>
> You can't flock SHARED... that denies everyone (including yourself)
> write access to the file.  Please review the FileLockEx docs.
>

I did. APR_FLOCK_EXCLUSIVE maps to LOCKFILE_EXCLUSIVE_LOCK which locks out
all reads and writes. APR_FLOCK_SHARED is what you are calling
APR_FLOCK_WRITE (which does not exist) and allows multiple readers but only
one writer.

Bill

RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows

[Bill Stoddard <bi...@wstoddard.com>]

> At 12:52 PM 10/25/2002, Bill Stoddard wrote:
> >The point of my comment was that this is irrelevant for what I
> am interested
> >in talking about.
> >
> >But since we are on the topic... APR_XTHREAD implies the file needs to be
> >opened for overlapped i/o.  Files opened for overlapped i/o don't HAVE OS
> >maintained file pointers. I assume (correct me if I am wrong) that
> >APR_APPEND has the same semantic meaning as Unix O_APPEND.  If that
> >assumption is correct, then passing in
> APR_XTHREAD|APR_FILE_APPEND on an apr_file_open is not correct
> and should be flagged as an error at file open
> >time.  My inclination is to make the check at file_open time
> rather than in
> >this code.
>
> Nope.  APR_XTHREAD files must be readable, writeable and totally
> compatible with APR_APPEND.

That's not possible assuming APR_APPEND has the same semantic meaning as
Unix O_APPEND.

> It's a couple of extra LOC, please add
> them or post the final patch for me to massage.  These files have APR
> maintained file pointers for compatibility with the API.

Yes, if the file is opened with APR_BUFFERED, then APR maintains it's own
file pointers. My patch is not touching the APR_BUFFERED path.

Bill