apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: apr_file_*() threading issues under Windows!
Date Fri, 08 Oct 2010 15:45:03 GMT
 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