Joe Orton wrote:
> On Mon, May 14, 2007 at 09:54:10AM -0300, Davi Arnaut wrote:
>> Joe Orton wrote:
>>> On Fri, May 11, 2007 at 10:38:01PM -0300, Davi Arnaut wrote:
The patches improves the locking interaction with buffering. But, quite
frankly, the unix file_io locking and buffering is a
On Mon, May 14, 2007 at 09:54:10AM -0300, Davi Arnaut wrote:
> Joe Orton wrote:
> > On Fri, May 11, 2007 at 10:38:01PM -0300, Davi Arnaut wrote:
> >> The patches improves the locking interaction with buffering. But, quite
> >> frankly, the unix file_io locking and buffering is a bit messed. There
>
Joe Orton wrote:
> On Fri, May 11, 2007 at 10:38:01PM -0300, Davi Arnaut wrote:
>> The patches improves the locking interaction with buffering. But, quite
>> frankly, the unix file_io locking and buffering is a bit messed. There
>> is no clear indication which functions are protected by APR_XTHREAD
On Fri, May 11, 2007 at 10:38:01PM -0300, Davi Arnaut wrote:
> The patches improves the locking interaction with buffering. But, quite
> frankly, the unix file_io locking and buffering is a bit messed. There
> is no clear indication which functions are protected by APR_XTHREAD,
> checks for partial
On Sat, 2007-05-12 at 09:32 -0300, Davi Arnaut wrote:
> No, but this:
>
> +#define file_lock(f) { .. }
> +#define file_unlock(f) { .. }
>
> should be:
>
> #define file_lock(f) do { .. } while (0)
> #define file_unlock(f) do { .. } while (0)
>
> or else it will break for expressions like:
>
Bojan Smojver wrote:
> On Fri, 2007-05-11 at 22:38 -0300, Davi Arnaut wrote:
>
>> The patches improves the locking interaction with buffering.
>
> Looking at the inline functions file_lock/unlock, wouldn't it be a bit
> more appropriate to do them as macros? I'm thinking on platforms that
> have
On Fri, 2007-05-11 at 22:38 -0300, Davi Arnaut wrote:
> The patches improves the locking interaction with buffering.
Looking at the inline functions file_lock/unlock, wouldn't it be a bit
more appropriate to do them as macros? I'm thinking on platforms that
have a C compiler that doesn't understa
On Sat, 2007-05-12 at 02:22 -0300, Davi Arnaut wrote:
> 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.
Cool. I can revert that function then.
--
Bojan
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
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
Bojan Smojver wrote:
> On Fri, 2007-05-11 at 15:58 +0100, Joe Orton wrote:
>
>> Yes, that looks necessary.
>
> Thanks, cool. Will implement. Honestly, even apr_file_flush() looks a
> bit suspect to me.
>
I've just posted a few initial patches to bugzilla, PR 42400. (passes
testfile)
The patche
On Fri, 2007-05-11 at 15:58 +0100, Joe Orton wrote:
> Yes, that looks necessary.
Thanks, cool. Will implement. Honestly, even apr_file_flush() looks a
bit suspect to me.
> Yup. BTW can you add CHANGES entries (on both 1.2.x and 0.9.x branches)
> listing the PR 40963 fix?
Will do, together wit
On Fri, May 11, 2007 at 01:39:15PM +1000, Bojan Smojver wrote:
> At present, we have in this function:
>
> if (thefile->buffered) {
> flush
> adjust various buffer offsets
> }
>
> If two threads do this for the same file (i.e. apr_file_t*), offsets may
> end up screwed. Shouldn't we surround
13 matches
Mail list logo
