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:
Hi,
while looking at potential backport to synch and trunk, I arrived on
r1619483.
This is a follow up of r1619444 which is a follow up of r1619383.
These 2 have been bakcported (see r1669555)
So I was wondering if r1619483 should also have been backported at the
same time?
Best regards,
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: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: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
Hi all,
I would like to propose a change to the mpm_register_socket_callback() hooks to
add the ability to support both pipes as well as sockets. In addition, I need
more control over the individual events to support the idea that one
socket/pipe might want to read at the same time another
+1
Really nice work
--
Daniel Ruggeri
On 3/13/2016 10:45 AM, Jim Jagielski wrote:
> I've given it a quick look-thru and I. Am. Impressed.
>
> This is more Super Cool Mojo!
I've given it a quick look-thru and I. Am. Impressed.
This is more Super Cool Mojo!
> On Mar 12, 2016, at 10:46 AM, Graham Leggett wrote:
>
> Hi all,
>
> The following patch provides support for TCP proxying to httpd.
>
> It consists of the following three parts:
>
> -
On 12 Mar 2016, at 6:26 PM, Eric Covener wrote:
> Very cool stuff. Only looked on the surface so far, but one thing it
> reminded me of in the async case is that the MPM knows the "suspended"
> count but we never gave an API to really "unsuspend" when using a
> timed or socket