Am 26.08.2013 17:48, schrieb Ivan Zhakov:
On Mon, Aug 26, 2013 at 7:41 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
On Mon, 26 Aug 2013 18:58:21 +0400
Ivan Zhakov <i...@visualsvn.com> wrote:
Alternative solution would be take file->lock mutex on write operation
and user shared OVERLAPPED structure. Also note that MSDN states that
opening file with FILE_APPEND permissions only will perform atomic
move-to-end + write without overlapped I/O.
Sure, that works for files, but apr_file_write is not strictly for
true file-based handles, right?
Sure, but I think APR_FOPEN_OPEN does makes sense only for files. And
we have file->append flag to check if file opened in append mode.
Some general thoughts... until apr_file_writev is called, we won't
need the append file lock. But... we need to mutex against the
parallel calls to apr_file_writev so we can't create the mutex to
interlock at that moment.
Note that this doesn't solve problem with several processes appending
to same file.
Yes, I encounterd this problem three years ago and filed a bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50058
If you open a file in append mode under Windows and use your own file
locking calling the following sequence:
apr_file_open(FOPEN_APPEND);
apr_file_lock();
apr_file_write();
apr_file_write();
apr_file_write();
apr_file_unlock();
apr_file_close();
It will deadlock under Windows. Under Linux it works fine.
For my usage scenario an implementation of
apr_file_lock()/apr_file_unlock() which supports nested calls would
work. Then apr_file_writev() could also use a
apr_file_lock()/apr_file_unlock() pair. What do you think?
Stefan
