apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: Regarding apr_file_writev() and locking...
Date Sat, 12 May 2007 05:22:45 GMT
Bojan Smojver wrote:
> On Fri, 2007-05-11 at 22:38 -0300, Davi Arnaut wrote:
> 
>> I've just posted a few initial patches to bugzilla, PR 42400. (passes
>> testfile)
> 
> Thanks. I had a brief look through and they seem nice. I will test to
> confirm.
> 
> I see you switched the mutex to nested. I think I can then revert the
> code for file_read_buffered() - the nested mutex would take care of that
> now.
> 
> The alternative approach would be to do apr_file_flush() in two parts -
> public (with locking) and private (no locking). However, I have no idea
> if nested mutex is greater overhead than another function call.

On my machine (Pentium D CPU 2.66GHz, dual core) testlockperf shows (in
some runs) that  the NESTED mutex is actually faster then the UNNESTED.

apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED)          OK
    Starting 1 threads    OK
microseconds: 91388 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED)            OK
    Starting 1 threads    OK
microseconds: 87852 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED)          OK
    Starting 2 threads    OK
microseconds: 786738 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED)            OK
    Starting 2 threads    OK
microseconds: 784970 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED)          OK
    Starting 3 threads    OK
microseconds: 1186499 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED)            OK
    Starting 3 threads    OK
microseconds: 884517 usec

>> I am in the middle of writing a patch that converts all file_io to
>> standard i/o functions (stdio/streams) so we can remove all code
>> involving buffering, file positioning and even locking at some cases. It
>> saves a huge amount of code lines, and I hope, gives fewer bugs.
>>
>> Comments?
> 
> I would venture I guess that this would be trunk stuff only. But maybe
> others feel something like that can go into 1.2.x/0.9.x.

trunk stuff.

> Anyhow, I'm sure someone will point out the history of buffered code and
> why a rewrite of stdio stuff happened in the fist place.
> 

Yes, please. I saw in the svn log history, but I couldn't find the exact
commit.

--
Davi Arnaut

Mime
View raw message