Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

2016-03-13 Thread Graham Leggett
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:

r1619483

2016-03-13 Thread Christophe JAILLET
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,

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

2016-03-13 Thread Eric Covener
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.

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

2016-03-13 Thread Graham Leggett
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

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

2016-03-13 Thread Eric Covener
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

Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

2016-03-13 Thread Graham Leggett
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

Re: [Patch] mod_tcp / mod_proxy_tcp / mod_ssl_tcp

2016-03-13 Thread Daniel Ruggeri
+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!

Re: [Patch] mod_tcp / mod_proxy_tcp / mod_ssl_tcp

2016-03-13 Thread Jim Jagielski
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: > > -

Re: [Patch] mod_tcp / mod_proxy_tcp / mod_ssl_tcp

2016-03-13 Thread Graham Leggett
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