Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows

[Ivan Zhakov <iv...@visualsvn.com>]

On 26 August 2013 at 20:13, Stefan Ruppert <sr...@myarm.com> wrote:
> 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 <iv...@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?
>
Just for the records: the problem described above has been fixed in r1806608 [1]

https://svn.apache.org/r1806608

-- 
Ivan Zhakov