httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: Implementing split() on pipe buckets?
Date Sun, 12 Nov 2000 02:48:26 GMT

--- rbb@covalent.net wrote:
> This patch fixes the problem of a pipe split where there is enough data in
> the pipe to split at the desired length, because it splits the pipe into a
> heap and a pipe bucket at the correct place.  What if there isn't enough
> data to do the split at the correct place?  This patch doesn't handle that
> case.  All the other bucket types return an error if the split is past the
> end of the bucket.

That's why I mentioned in my preceding comments that pipe_split() might want to
check the value of *len after calling pipe_readn(), comparing it to the value it
passed in.  If the two differ, then there wasn't enough data in the pipe to split at
the right place.  In that case, APR_EINVAL would be returned.  The pipe bucket would
have been morphed in the process, but that's going to happen as soon as you read it
anyway.

> The only logical way to deal with pipe and socket splits is to read the
> data and then split it.  The split functions can't do this, because that
> changes the definition of split, so it is up to the program itself.

But pipe_read() IS a split function, if you think about it.  Its only shortcomings
if it wants to become pipe_split() are that it needs to obey the passed in length
and that it needs to have the right parameter list.  That's all!  When you read from
pipe_readn(), it does the split for you!  There's no need to try to split, find out
you can, then read... why not just let the pipe bucket do the read for you?

If I understand your argument, it's just that you dislike the idea of there being
any side effects of split() (ie, that the pipe bucket gets morphed into a heap+pipe
sequence of buckets).  But read() already has that side effect!  A pipe doesn't do
you much good if you're not willing to read from it.  At some point, the server is
going to have to read from that pipe to be able to use the data.  What am I missing?
 Why is it bad for a pipe bucket to become a heap+pipe sequence automatically if the
caller is going to have to do it anyway (and in the process lose ability to specify
how much data it wants read out of the pipe, since pipe_read() ignores the passed in
length just like all of the other read functions)?

> I am also against some of the malloc checks.  In general in Apache, we do
> not check for NULL after calling malloc, because if malloc returns NULL
> your machine is basically screwed and we can't really fail cleanly anyway.

I was just responding to the XXX comments.  If you don't think Apache should make
these checks, no problem (since you're 100% right that the box is essentially fubar
if malloc fails)... just nuke the XXX comments.

--Cliff

__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

Mime
View raw message