On Sun, Mar 13, 2016 at 4:29 PM, Graham Leggett wrote:
> What I have in mind is to swap the apr_socket_t with a apr_pollfd_t, with all
> operation staying the same.
I don't think I had a good reason for going one way or the other, +1
here. Trunk-only and presumably nobody consuming it from the
On 13 Mar 2016, at 10:53 PM, Eric Covener wrote:
> I don't think I had a good reason for going one way or the other, +1
> here. Trunk-only and presumably nobody consuming it from the lack of
> feedback.
From what I can see, this was never backported to v2.4.
Regards,
Graham
—
On Sun, Mar 13, 2016 at 4:54 PM, Graham Leggett wrote:
> From what I can see, this was never backported to v2.4.
I also meant the original feature never made it, so we can whatever we
want to it.
On 13 Mar 2016, at 10:55 PM, Eric Covener wrote:
> I also meant the original feature never made it, so we can whatever we
> want to it.
What do you think of this?
It includes a cleanup to the original pool to remove any unfired pollsets from
the core.
Index: include/ap_mpm.h
=
On Mon, Mar 14, 2016 at 12:41 AM, Graham Leggett wrote:
> On 13 Mar 2016, at 10:55 PM, Eric Covener wrote:
>
>> I also meant the original feature never made it, so we can whatever we
>> want to it.
>
> What do you think of this?
Looks good and indeed very valuable to me, s/socket/pollfd/ is a gr
> Am 14.03.2016 um 09:32 schrieb Yann Ylavic :
>
> On Mon, Mar 14, 2016 at 12:41 AM, Graham Leggett wrote:
>> On 13 Mar 2016, at 10:55 PM, Eric Covener wrote:
>>
>>> I also meant the original feature never made it, so we can whatever we
>>> want to it.
>>
>> What do you think of this?
>
> Lo
On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote:
> Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could
> remove the indirection here (and in the code below) with somthing like
> (apr_pollfd_t *pfds, size_t npfds, ...).
> That would allow a single allocation (all pfds in once) an
> On Mar 14, 2016, at 7:07 AM, Graham Leggett wrote:
>
> On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote:
>
>> Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could
>> remove the indirection here (and in the code below) with somthing like
>> (apr_pollfd_t *pfds, size_t npfds, .
On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote:
> Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could
> remove the indirection here (and in the code below) with somthing like
> (apr_pollfd_t *pfds, size_t npfds, ...).
> That would allow a single allocation (all pfds in once) an
On Mon, Mar 14, 2016 at 8:51 PM, Graham Leggett wrote:
> On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote:
>
>> Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could
>> remove the indirection here (and in the code below) with somthing like
>> (apr_pollfd_t *pfds, size_t npfds, ...)
On 14 Mar 2016, at 11:17 PM, Yann Ylavic wrote
:
>> Having looked at this in more detail this isn’t as simple.
>>
>> The sticking point is the cleanup, which needs to be passed a single struct
>> to do it’s work. To pass both the pfds and the npdfs these two need to be
>> wrapped in a structure
On 14 Mar 2016, at 11:13 AM, Stefan Eissing
wrote:
> Like the direction this is going as well.
>
> Do we need a MPM Query for detecting support before one actually has a handle
> for registration?
We do - most recent patch has that, and we managed to drop one directive out of
mod_proxy_wstunn
On Mon, Mar 14, 2016 at 11:29 PM, Graham Leggett wrote:
> On 14 Mar 2016, at 11:17 PM, Yann Ylavic wrote
> :
>>> Having looked at this in more detail this isn’t as simple.
>>>
>>> The sticking point is the cleanup, which needs to be passed a single struct
>>> to do it’s work. To pass both the pf
On 15 Mar 2016, at 1:09 PM, Yann Ylavic wrote:
>> I just gave it a try and it was a lot more elegant than I thought.
>>
>> You create an array the precise size you need, and off you go.
>
> That's indeed elegant enough, but I think I prefer the plain array
> solution, still :p
>
> Don't you li
On Tue, Mar 15, 2016 at 8:28 PM, Graham Leggett wrote:
>
> The trouble with the above is that because of the pool cleanup we now have,
> pfds[3] needs to live as long as pool p. In your example it does, but there
> is nothing stopping someone trying to allocate pfds[3] on the stack and then
> r
> On Mar 15, 2016, at 3:28 PM, Graham Leggett wrote:
>
> The trouble with the above is that because of the pool cleanup we now have,
> pfds[3] needs to live as long as pool p. In your example it does, but there
> is nothing stopping someone trying to allocate pfds[3] on the stack and then
> r
16 matches
Mail list logo
