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 Sat, Feb 18, 2017 at 4:25 PM, Daniel Ruggeri wrote:
> On 2017-02-15 09:07 (-0600), William A Rowe Jr wrote:
>> On Wed, Feb 15, 2017 at 9:02 AM, Sander Hoentjen wrote:
>> >
>> > mod_remote ip has:
>> > /* mod_proxy creates outgoing connections - we don't want those */
>> > if (!remotei
On Mon, Feb 20, 2017 at 10:16 AM, Joe Orton wrote:
>
> FYI, since I've seen people thinking seriously about test suites, this
> kind of issue is impossible to test comprehensively with the current
> test framework. We really need to spin up httpd multiple times with
> different configurations, to
My 2c! It would be great to see a little CHANGES entry, it might be useful
for people checking new mpm-features of the next httpd release (reviewing
the commit logs might be a bit overkill for some users).
Luca
2017-02-18 14:47 GMT+01:00 Jim Jagielski :
> CHANGES is usually for PR listing and si
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
Fair enuff... sounds like thread safe pools aren't something
people are interested in, so I won't worry about it :)
thx for the discussion!
On Mon, Feb 20, 2017 at 5:55 PM, Jim Jagielski wrote:
>
>>
>> It could be done, but who would use it that way?
>>
>
> I think the non-thread safety of pools requires that each
> person/developer implement their own locking esp around areas
> where they might not even understand that there is cross
On Sat, Feb 18, 2017 at 4:44 PM, Daniel Ruggeri wrote:
>
> Hi, Bill;
>I've replied about the pre_connnection situation - hoping someone can
> give the proposed patch a test as I don't have a handy H2 testbed.
Yup! Will review that thread - it's the -1 half (as opposed to a general -0 half
for
>
> It could be done, but who would use it that way?
>
I think the non-thread safety of pools requires that each
person/developer implement their own locking esp around areas
where they might not even understand that there is cross-thread
issues. Thinking about 1.6 and especially apr 2.0, it m
On Mon, Feb 20, 2017 at 5:32 PM, Yann Ylavic wrote:
>
> First you want it to be Off by default (i.e. verify the OCSP's
> responder certificate when not configured), right?
> Couldn't that break existing configurations since we currently (until
> 2.4.25) do not verify it?
Oh, we do verify uncondit
[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
> Am 20.02.2017 um 17:22 schrieb Jim Jagielski :
>
>
>> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote:
>>
>>
>> So as Brane says, if one sets a mutex to the allocator of a pool
>> because (s)he wants pool_create/destroy() to be thread-safe, it does
>> not necessarily wants the same for pall
Hi Jean-Frédéric,
On Fri, Feb 3, 2017 at 5:19 PM, wrote:
> Author: jfclere
> Date: Fri Feb 3 16:19:17 2017
> New Revision: 1781575
>
> URL: http://svn.apache.org/viewvc?rev=1781575&view=rev
> Log:
> Add Configuration for trusted OCSP responder certificates
> Fix for PR 46037
>
> Modified:
>
> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote:
>
>
> So as Brane says, if one sets a mutex to the allocator of a pool
> because (s)he wants pool_create/destroy() to be thread-safe, it does
> not necessarily wants the same for palloc() and friends (e.g. the pool
> is used by a single thread)
On Fri, Feb 17, 2017 at 12:38:30PM -0500, Eric Covener wrote:
> +1
>
> On Fri, Feb 17, 2017 at 12:37 PM, William A Rowe Jr
> wrote:
> > Great catch; +1 to commit to 2.2.x and
> > http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x-merge-http-strict/
> > branches.
> >
> > And thanks for ad
apr_pool_create_ex_debug(), yes.
> On Feb 20, 2017, at 11:00 AM, Yann Ylavic wrote:
>
> Well, this is for debug mode only I guess.
>
> On Mon, Feb 20, 2017 at 4:59 PM, Jim Jagielski wrote:
>> Please READ apr_pools.c... Search for '->mutex'
>>
>>> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wro
Well, this is for debug mode only I guess.
On Mon, Feb 20, 2017 at 4:59 PM, Jim Jagielski wrote:
> Please READ apr_pools.c... Search for '->mutex'
>
>> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote:
>>
>> On Mon, Feb 20, 2017 at 4:43 PM, Jim Jagielski wrote:
>>> You are confusing pool mutexes
> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote:
>
>
> APR pools were designed with the assumption that separate threads will
> always use separate pools whenever concurrent allocations are possible.
> This assumption happens to fit pretty well with the
> server/worker/thread-pool architectu
Please READ apr_pools.c... Search for '->mutex'
> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote:
>
> On Mon, Feb 20, 2017 at 4:43 PM, Jim Jagielski wrote:
>> You are confusing pool mutexes with allocator mutexes...
>
> I'm not sure to understand, there is no pool mutex per se currently,
> th
On Mon, Feb 20, 2017 at 4:43 PM, Jim Jagielski wrote:
> You are confusing pool mutexes with allocator mutexes...
I'm not sure to understand, there is no pool mutex per se currently,
the mutex (if any) used by the pool is its allocator's.
So as Brane says, if one sets a mutex to the allocator of
You are confusing pool mutexes with allocator mutexes...
> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote:
>
> On 20.02.2017 16:08, Jim Jagielski wrote:
>> Again, this would ONLY happen if the underlying allocator has
>> a mutex!
>
> Sure, but you need an allocator with a mutex in order to sa
I mean, of course, "has a *mutex*"
> On Feb 20, 2017, at 10:39 AM, Jim Jagielski wrote:
>
> Again, I am only talking about those in which the allocator
> has a pool... The allocator. Via apr_allocator_mutex_set().
>
>> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote:
>>
>> On 20.02.2017 16:
Again, I am only talking about those in which the allocator
has a pool... The allocator. Via apr_allocator_mutex_set().
> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote:
>
> On 20.02.2017 16:08, Jim Jagielski wrote:
>> Again, this would ONLY happen if the underlying allocator has
>> a mutex!
On Wed, Feb 15, 2017 at 8:53 PM, Stefan Priebe - Profihost AG
wrote:
>
> still no segfaults.
Great!
>
> @Yann
> Are those patches (the addon on top of v7) and the one on top of mod_ssl
> still correct / needed?
I think so, but maybe I'm a bit lost (see below)...
>
> Am 15.02.2017 um 12:45 schr
On 20.02.2017 16:08, Jim Jagielski wrote:
> Again, this would ONLY happen if the underlying allocator has
> a mutex!
Sure, but you need an allocator with a mutex in order to safely create
pools in a multi-threaded environment. For all practical purposes this
means that the allocator must be thread
Not with apr_palloc() or anything that calls apr_palloc (eg apr_pcalloc,
et.al...)
> On Feb 20, 2017, at 10:15 AM, Stefan Eissing
> wrote:
>
>>
>> Am 20.02.2017 um 16:08 schrieb Jim Jagielski :
>>
>> Again, this would ONLY happen if the underlying allocator has
>> a mutex!
>
> But isn't tha
> Am 20.02.2017 um 16:08 schrieb Jim Jagielski :
>
> Again, this would ONLY happen if the underlying allocator has
> a mutex!
But isn't that now true for all conn_rec->pool and thus r->pool and
c->bucket_alloc etc?
>
>> On Feb 20, 2017, at 10:06 AM, Branko Čibej wrote:
>>
>> On 20.02.2017 15
Again, this would ONLY happen if the underlying allocator has
a mutex!
> On Feb 20, 2017, at 10:06 AM, Branko Čibej wrote:
>
> 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 :
>>>
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
Now everything is working again here. Thanks.
-Stefan
> Am 20.02.2017 um 15:21 schrieb Yann Ylavic :
>
> On Mon, Feb 20, 2017 at 3:08 PM, ste...@eissing.org
> wrote:
>> Uhm, don't know what it is, but trunk runs out of open files in my load
>> tests now after a few seconds...
>
> This commit
On Mon, Feb 20, 2017 at 3:08 PM, ste...@eissing.org wrote:
> Uhm, don't know what it is, but trunk runs out of open files in my load tests
> now after a few seconds...
This commit is garbage (reverted in r1783760).
Can you still reproduce in HEAD (of now)?
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
Uhm, don't know what it is, but trunk runs out of open files in my load tests
now after a few seconds...
> Am 20.02.2017 um 14:50 schrieb yla...@apache.org:
>
> Author: ylavic
> Date: Mon Feb 20 13:50:49 2017
> New Revision: 1783759
>
> URL: http://svn.apache.org/viewvc?rev=1783759&view=rev
> L
> Am 20.02.2017 um 10:36 schrieb Stefan Priebe :
>
> Hi,
>
> still not a single segfault with mod_http2 1.9.0 - good work!
Thanks! Our pleasure. Enjoy it until I break something in the next releases.
> @Yann
> Could you please tell me whether i should drop of your additional patches?
>
> Gre
On Mon, Feb 20, 2017 at 10:36 AM, Stefan Priebe wrote:
>
> @Yann
> Could you please tell me whether i should drop of your additional patches?
Sorry Stefan, somehow I missed you message.
I'll reply (inline) on the other thread.
On 02/18/2017 11:07 PM, Daniel Ruggeri wrote:
> On 2/6/2017 2:51 PM, Ruediger Pluem wrote:
>>
>> On 02/04/2017 09:14 PM, drugg...@apache.org wrote:
>>> Author: druggeri
>>> Date: Sat Feb 4 20:14:18 2017
>>> New Revision: 1781701
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1781701&view=rev
>>>
Hi,
still not a single segfault with mod_http2 1.9.0 - good work!
@Yann
Could you please tell me whether i should drop of your additional patches?
Greets,
Stefan
Am 09.02.2017 um 11:55 schrieb Stefan Priebe - Profihost AG:
Hi Stefan,
Am 09.02.2017 um 11:47 schrieb Stefan Eissing:
Stefan,
a
On Mon, 20 Feb 2017, Yann Ylavic wrote:
On Sun, Feb 19, 2017 at 10:11 PM, Niklas Edmundsson wrote:
On Thu, 16 Feb 2017, Yann Ylavic wrote:
Here I am, localhost still, 21GB file (client wget -qO- [url]
&>/dev/null).
Output attached.
Looks good with nice big writes if I interpret it correctl
On Sun, Feb 19, 2017 at 10:11 PM, Niklas Edmundsson wrote:
> On Thu, 16 Feb 2017, Yann Ylavic wrote:
>>
>> Here I am, localhost still, 21GB file (client wget -qO- [url]
>> &>/dev/null).
>> Output attached.
>
> Looks good with nice big writes if I interpret it correctly.
>
> Is this without patchin
45 matches
Mail list logo
