Re^4: [patch] perchild.c

[Tsuyoshi SASAMOTO <na...@super.win.ne.jp>]

>attached patch looks a bit simpler; does it look okay to you?

Yes, it looks good and smart.

# I wonder about intention of the original code `if (!body)`;
# in what case could it occur... recvmsg() could fail?
# If so, rather return value of the recvmsg() should be checked...


Tsuyoshi SASAMOTO
nazonazo@super.win.ne.jp

Re: Re^4: [patch] perchild.c

[Jeff Trawick <tr...@gmail.com>]

On Tue, 3 Aug 2004 11:45:51 +0900 (JST), Tsuyoshi SASAMOTO
<na...@super.win.ne.jp> wrote:
> >attached patch looks a bit simpler; does it look okay to you?
> 
> Yes, it looks good and smart.
> 
> # I wonder about intention of the original code `if (!body)`;

if we received a message, it will have the '\0' in it (or there is a
bug in the send logic); so I'm not worried about the original check
for if (!body)...

> # in what case could it occur... recvmsg() could fail?

looks like pass_request() is what does the sendmsg(), yet there is an
error path in there -- when apr_brigade_flatten() fails; on this error
path, the connection to the recvmsg() loop would be dropped with no
sendmsg(), so recvmsg() would return a failure

> # If so, rather return value of the recvmsg() should be checked...

another thing I wonder about with regards to this AF_UNIX/SOCK_STREAM
logic: SOCK_STREAM isn't normally message oriented, but no logic on
the receive side to handle a partial read; when will that blow up?

I suspect (but haven't done the testingresearch) that the only thing
we can assume is sent over intact is the file escriptor that is
getting passed, and the receiver should be prepared to continue
reading after calling recvmsg()

--/--

also, why send over the request body on this initial "message"? how
would the request body get filtered?  seems like we should let the
process which is going to handle this request read the request body
through the input filter chain