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
