apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Ruppert ...@myarm.com>
Subject Re: apr_file_*() threading issues under Windows!
Date Fri, 08 Oct 2010 15:54:56 GMT
I do not use a file handle from different threads. But if this is not a 
valid usage scenario why protected some piece of code with a mutex??

Also a couple of weeks ago there was a discussion about performance 
where these mutex operation are involved. Thus if the apr_file_*() 
functions are designed to be not thread-safe, why use mutexes at all??

I personally prefer that the application has to decide if it uses a file 
from different threads and therefore has to protect the operations by 
itselt.

Stefan

Branko ─îibej wrote:
>  Are you trying to use the same apr_file_t handle simultaneously in
> different threads? AFAIK it was never meant to work that way.
> 
> On 08.10.2010 14:34, Stefan Ruppert wrote:
>> Hi all,
>>
>> after digging into the apr_file_*() source code for Windows I have
>> found several issues regading file io and threading under Windows.
>>
>> In general is there a document which explains which functions are
>> thread-safe and which not?
>>
>> * Allocation of pOverlapped structure is not thread-safe (readwrite.c):
>>
>> The allocation of the pOverlapped structure is not guarded by a mutex,
>> thus this can lead into undefined behavior (memory leak, resource leak
>> (CreateEvent)) if two threads enters apr_file_read()/apr_file_write()
>> at the same time!
>>
>> Why not allocating this structure within apr_file_open() if XTHREAD
>> was specified?
>>
>> * Usage of the mutex is not consistent.
>>
>> Sometimes it is used with if(thefile->flags & APR_FOPEN_XTHREAD) and
>> sometimes without such an condition!
>>
>> * apr_file_flush() for flushing the buffer does not use the mutex at all!
>>
>> * apr_file_buffer_set() is broken (buffer.c).
>>
>> The mutex is unconditionally used within apr_file_buffer_set(). But a
>> mutex is only created within apr_file_open() if APR_FOPEN_APPEND or
>> APR_FOPEN_BUFFERED is specified.
>>
>> Also the docs of apr_file_buffer_set() documents that someone can
>> later add APR_FOPEN_BUFFERED support by calling it. But a mutex is
>> not created if it was not created by apr_file_open()!
>>
>> * The preprocessor APR_HAS_THREADS inconsistently used.
>>
>> Within filedup.c APR_HAS_THREADS is used to compile out some calls
>> to the apr_thread_*() functions and sometimes it is not used.
>>
>> Any comments?
>>
>> Regards,
>> Stefan
> 
> 
> 

Mime
View raw message