On 26 August 2013 at 20:13, Stefan Ruppert <s...@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 <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? > Just for the records: the problem described above has been fixed in r1806608 [1]
https://svn.apache.org/r1806608 -- Ivan Zhakov