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

> 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

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

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

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

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,

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

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

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

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

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

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 >>

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

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

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

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

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

> 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

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

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

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

> 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

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

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

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

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:

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

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

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

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

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