apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Ruppert ...@myarm.com>
Subject Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
Date Mon, 26 Aug 2013 17:13:07 GMT
Am 26.08.2013 17:48, schrieb Ivan Zhakov:
> On Mon, Aug 26, 2013 at 7:41 PM, William A. Rowe Jr.
> <wrowe@rowe-clan.net> wrote:
>> On Mon, 26 Aug 2013 18:58:21 +0400
>> Ivan Zhakov <ivan@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:

If you open a file in append mode under Windows and use your own file 
locking calling the following sequence:


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?


View raw message