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 Mon, 11 Oct 2010 06:52:30 GMT
Bert Huijben wrote:
>> -----Original Message----- From: Stefan Ruppert
>> [mailto:sr@myarm.com] Sent: vrijdag 8 oktober 2010 17:55 To:
>> dev@apr.apache.org Subject: Re: apr_file_*() threading issues under
>> Windows!
>> 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.
> In the early days of APR, httpd used threads on Windows and workers
> on other systems. And most likely to keep things easy mutexes were
> used to protect the file handles in some Windows scenarios. (If you
> look at the history you will find that some other OSs had mutexes
> too, but those were removed over the years)
> The only documented safe way to use a file in multiple threads at
> once (that should work on multiple Oss) is with APR_FOPEN_XTHREAD.
> The mutexes are currently slowing down IO on Windows; especially on
> multi CPU-systems, because they were simply never removed for
> Windows. And I would really like to see them removed where possible.
> (Ivan Zhakov already started working on this for some Subversion
> performance critical code paths)

Ok, so from my point of view any mutex operation should only be used if 
the APR_FOPEN_XTHREAD flag was specified. We at MyARM uses the 
apr_file_*() API especially for an platform independend way to use file 
locking. And we don't want the overhead of mutex operations which are 
not needed!

I'll file a bug report to track this issue and add the appropriate patches.


View raw message