On Tue, Feb 21, 2017 at 3:12 PM, Stefan Eissing
wrote:
>
> I think at this stage, let's get all changes/reverts into trunk. When that is
> all done, we can talk about changes that I "expect" to work additionally.
Reverted now (but the allocator mutex in h2_slave_create(), up to you ;)
> Am 21.02.2017 um 14:54 schrieb Yann Ylavic :
>
> We seem to be talking past each other, I'll _try_ to synchronize ourselves :)
We'll get there! :)
> On Tue, Feb 21, 2017 at 1:57 PM, Stefan Eissing wrote:
>>
>> You have me confused now. If you did that all only for h2, then, I
>> think, we ca
We seem to be talking past each other, I'll _try_ to synchronize ourselves :)
On Tue, Feb 21, 2017 at 1:57 PM, Stefan Eissing wrote:
>
> You have me confused now. If you did that all only for h2, then, I
> think, we can live without them all nowadays, because:
Actually I made the MPMs change most
> Am 21.02.2017 um 13:42 schrieb Yann Ylavic :
>
> On Mon, Feb 20, 2017 at 6:29 PM, Yann Ylavic wrote:
>> On Mon, Feb 20, 2017 at 6:21 PM, Stefan Eissing
>> wrote:
>>>
>>> 1+2, so the only allocator is from master conn_rec.
>>
>> The allocator with a mutex (after r1783755)?
>
> Sorry to insi
On Mon, Feb 20, 2017 at 6:29 PM, Yann Ylavic wrote:
> On Mon, Feb 20, 2017 at 6:21 PM, Stefan Eissing
> wrote:
>>
>> 1+2, so the only allocator is from master conn_rec.
>
> The allocator with a mutex (after r1783755)?
Sorry to insist Stefan, I see a reason why it would fail without
r1783755 (thi
On Tue, Feb 21, 2017 at 12:47 PM, Jim Jagielski wrote:
>
>> On Feb 20, 2017, at 3:54 PM, Ruediger Pluem wrote:
>>
>>
>>
>> On 02/20/2017 02:38 PM, yla...@apache.org wrote:
>>> Author: ylavic
>>> Date: Mon Feb 20 13:38:03 2017
>>> New Revision: 1783755
>>>
>>> URL: http://svn.apache.org/viewvc?rev
> On Feb 20, 2017, at 3:54 PM, Ruediger Pluem wrote:
>
>
>
> On 02/20/2017 02:38 PM, yla...@apache.org wrote:
>> Author: ylavic
>> Date: Mon Feb 20 13:38:03 2017
>> New Revision: 1783755
>>
>> URL: http://svn.apache.org/viewvc?rev=1783755&view=rev
>> Log:
>> mpm_event: use a mutex for ptrans'
On Mon, Feb 20, 2017 at 10:48 PM, Yann Ylavic wrote:
>
> The hard thing is that at the time ptrans is created, we don't know
> how it will be used.
> Maybe we could differ apr_allocator_mutex_set() at a later time, e.g.
> {pre,process}_connection hook?
Theorically though, a module that creates mu
On Mon, Feb 20, 2017 at 9:54 PM, Ruediger Pluem wrote:
>
>
> On 02/20/2017 02:38 PM, yla...@apache.org wrote:
>> Author: ylavic
>> Date: Mon Feb 20 13:38:03 2017
>> New Revision: 1783755
>>
>> URL: http://svn.apache.org/viewvc?rev=1783755&view=rev
>> Log:
>> mpm_event: use a mutex for ptrans' allo
On 02/20/2017 02:38 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Mon Feb 20 13:38:03 2017
> New Revision: 1783755
>
> URL: http://svn.apache.org/viewvc?rev=1783755&view=rev
> Log:
> mpm_event: use a mutex for ptrans' allocator to be safe with concurrent
> creation and destruction of its
On Mon, Feb 20, 2017 at 6:21 PM, Stefan Eissing
wrote:
>
> 1+2, so the only allocator is from master conn_rec.
The allocator with a mutex (after r1783755)?
> Am 20.02.2017 um 17:41 schrieb Yann Ylavic :
>
> [Keeping httpd list here only]
>
> On Mon, Feb 20, 2017 at 3:51 PM, Stefan Eissing
> wrote:
>>
>> So, apr_p*alloc() calls would be thread-safe if a mutex is set in
>> the underlying allocator? Hmm, at what cost? would be my question.
>
> I a
[Keeping httpd list here only]
On Mon, Feb 20, 2017 at 3:51 PM, Stefan Eissing
wrote:
>
> So, apr_p*alloc() calls would be thread-safe if a mutex is set in
> the underlying allocator? Hmm, at what cost? would be my question.
I also fear that it would be costly when not needed (e.g. request's poo
On 20.02.2017 15:55, Jim Jagielski wrote:
>> On Feb 20, 2017, at 9:51 AM, Stefan Eissing
>> wrote:
>>
>>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski :
>>>
>>> The below got me thinking...
>>>
>>> Right now, the pool allocator mutex is only used when, well,
>>> allocator_alloc() is called, which
> On Feb 20, 2017, at 9:51 AM, Stefan Eissing
> wrote:
>
>>
>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski :
>>
>> The below got me thinking...
>>
>> Right now, the pool allocator mutex is only used when, well,
>> allocator_alloc() is called, which means that sometimes
>> apr_palloc(), for
> Am 20.02.2017 um 15:16 schrieb Jim Jagielski :
>
> The below got me thinking...
>
> Right now, the pool allocator mutex is only used when, well,
> allocator_alloc() is called, which means that sometimes
> apr_palloc(), for example, can be thread-safeish and sometimes
> not, depending on whethe
[Oups, meant to reach the list(s)].
On Mon, Feb 20, 2017 at 3:46 PM, Yann Ylavic wrote:
> On Mon, Feb 20, 2017 at 3:16 PM, Jim Jagielski wrote:
>> The below got me thinking...
>>
>> Right now, the pool allocator mutex is only used when, well,
>> allocator_alloc() is called, which means that some
The below got me thinking...
Right now, the pool allocator mutex is only used when, well,
allocator_alloc() is called, which means that sometimes
apr_palloc(), for example, can be thread-safeish and sometimes
not, depending on whether or not the active node has enough
space.
For 1.6 and later, it
18 matches
Mail list logo
