You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 1999/08/15 23:32:12 UTC
IOL and send_fb
There's this rather optimistic note in MPM that suggests we reimplement
send_fb (or, more particularly, send_fb_length). Snag is, it used to use
select(). Someone thinks it might now use poll(). But it can't really
use either, because of IOL. It also tries to use non-blocking I/O.
Again, IOL is a bit of a barrier. Does anyone have an ingenious plan
here, or is it simply a matter of extending IOL until this can work?
That is, does IOL have to support non-blocking IOLs and some kind of
IOLpoll?
Until this happens, CGI doesn't work, and that's a rather large hole in
MPM.
Of course, plan B is to implement CGI in some completely different
way...
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Process abstraction in MPM
Posted by Ben Laurie <be...@algroup.co.uk>.
Manoj Kasichainula wrote:
>
> On Sun, Aug 15, 1999 at 03:04:22PM -0700, Dean Gaudet wrote:
> > we still need process abstraction to help CGIs...
>
> What exactly do you mean here?
>
> I was looking into getting ap_bspawn_child working again a while back.
> First, why is it in alloc.c at all? I didn't spot any internal pool
> fiddling in there.
>
> It looks like the important piece needed is an iol_ layer for pipes,
> so that ap_bpush_iol can function.
Guess so: on most modern Unices, iol_socket will do (it uses select()
for timeout). Older ones will require a socketpair instead of a pipe,
and then iol_socket will still do.
> What else is needed?
Dunno, but if you are planning to make mod_cgi work, then please say so,
and I'll do something else.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Process abstraction in MPM
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> > We want:
> >
> > - an API similar to NSPR's process creation API which allows you to
> > specify:
> > - the current dir for the new process
> > - the initial fd set for the new process
> > - the path & args
> > - the environment
> > - rlimits
> >
> > which i think is pretty much what Ryan put in APR
> >
> > - wrappers which set up pipes
> >
> > - move all the !@#$ interpreter crap to os specific files
> >
> > Essentially all the callback stuff for post-fork should go away.
>
> ALL of this is in APR. It's just waiting for permission to use APR in the
> 2.0 tree. :)
I thought we'd agreed that, and the debate was simply about playing
games with CVS to make certain people happy? If that's the case, then
I'd say carry on and do it, and when people who want to play games with
CVS get around to doing it they'll have a bit more to do.
Certainly waiting while people argue about procedure and details is what
held up Apache 2.0 work for so long, so don't wait, get stuck in.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Process abstraction in MPM
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> We want:
>
> - an API similar to NSPR's process creation API which allows you to
> specify:
> - the current dir for the new process
> - the initial fd set for the new process
> - the path & args
> - the environment
> - rlimits
>
> which i think is pretty much what Ryan put in APR
>
> - wrappers which set up pipes
>
> - move all the !@#$ interpreter crap to os specific files
>
> Essentially all the callback stuff for post-fork should go away.
ALL of this is in APR. It's just waiting for permission to use APR in the
2.0 tree. :)
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: Process abstraction in MPM
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 16 Aug 1999, Manoj Kasichainula wrote:
> On Sun, Aug 15, 1999 at 03:04:22PM -0700, Dean Gaudet wrote:
> > we still need process abstraction to help CGIs...
>
> What exactly do you mean here?
>
> I was looking into getting ap_bspawn_child working again a while back.
> First, why is it in alloc.c at all? I didn't spot any internal pool
> fiddling in there.
This is one of the problems I mean. It's in there because it registers
cleanups.
> It looks like the important piece needed is an iol_ layer for pipes,
> so that ap_bpush_iol can function. What else is needed?
We want:
- an API similar to NSPR's process creation API which allows you to
specify:
- the current dir for the new process
- the initial fd set for the new process
- the path & args
- the environment
- rlimits
which i think is pretty much what Ryan put in APR
- wrappers which set up pipes
- move all the !@#$ interpreter crap to os specific files
Essentially all the callback stuff for post-fork should go away.
Dean
Process abstraction in MPM
Posted by Manoj Kasichainula <ma...@io.com>.
On Sun, Aug 15, 1999 at 03:04:22PM -0700, Dean Gaudet wrote:
> we still need process abstraction to help CGIs...
What exactly do you mean here?
I was looking into getting ap_bspawn_child working again a while back.
First, why is it in alloc.c at all? I didn't spot any internal pool
fiddling in there.
It looks like the important piece needed is an iol_ layer for pipes,
so that ap_bpush_iol can function. What else is needed?
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: IOL and send_fb
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Sun, 15 Aug 1999, Ben Laurie wrote:
>
> > BTW, this although we've managed to slide past it this time, I do have
> > this feeling of impending doom wrt to poll/select and IOL.
>
> anything which relies on poll/select isn't portable... we just barely
> squeak by as it is on NT don't we? for async stuff we want some other
> abstraction i think -- one which works for completion ports on NT and for
> poll/select on unix (or /dev/poll on solaris, or io signals on linux, or
> even async i/o on VMS :).
>
> one possibility is eventlib, which comes with bind (i used it ages ago for
> one of my prototypes)... but the ISC guys say to wait a bit -- they're
> working on a portable library (with NT and unix ports) which will do this
> sort of stuff, and support SMP/multithreading. i'll probably do the first
> crack of the async stuff using eventlib though, because i don't want to
> wait for the new library (and it doesn't sound hard to switch later).
>
> oh the other problem with poll/select on IOL is that you can't ask an
> arbitrary layer for a selectable object and hope to get something which
> always works... at best you need to ask a layer for a set of poll masks
> which it is interested in. whereas with something like eventlib, the
> layer can register its own events...
Err, yeah, that's the feeling of impending doom I had! That is, I
suspect we are going to need the facility, but it ain't portable. If you
are thinking of having a full-blown event handling library (which is
probably a damn good idea) then I have two comments:
a) Shouldn't it be part of APR?
b) Event libraries tend to end up being pretty pervasive (in their use),
so we'd better get cracking.
The downside is that a portable event library is pretty tricky stuff.
Especially if you want to support older 'nix - which have a tendency to
be picky about what you can select on and the like. Where do I find out
more about the ISC stuff?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: IOL and send_fb
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 15 Aug 1999, Ben Laurie wrote:
> BTW, this although we've managed to slide past it this time, I do have
> this feeling of impending doom wrt to poll/select and IOL.
anything which relies on poll/select isn't portable... we just barely
squeak by as it is on NT don't we? for async stuff we want some other
abstraction i think -- one which works for completion ports on NT and for
poll/select on unix (or /dev/poll on solaris, or io signals on linux, or
even async i/o on VMS :).
one possibility is eventlib, which comes with bind (i used it ages ago for
one of my prototypes)... but the ISC guys say to wait a bit -- they're
working on a portable library (with NT and unix ports) which will do this
sort of stuff, and support SMP/multithreading. i'll probably do the first
crack of the async stuff using eventlib though, because i don't want to
wait for the new library (and it doesn't sound hard to switch later).
oh the other problem with poll/select on IOL is that you can't ask an
arbitrary layer for a selectable object and hope to get something which
always works... at best you need to ask a layer for a set of poll masks
which it is interested in. whereas with something like eventlib, the
layer can register its own events...
Dean
Re: IOL and send_fb
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Sun, 15 Aug 1999, Ben Laurie wrote:
>
> > There's this rather optimistic note in MPM that suggests we reimplement
> > send_fb (or, more particularly, send_fb_length). Snag is, it used to use
> > select(). Someone thinks it might now use poll(). But it can't really
> > use either, because of IOL. It also tries to use non-blocking I/O.
> > Again, IOL is a bit of a barrier. Does anyone have an ingenious plan
> > here, or is it simply a matter of extending IOL until this can work?
> > That is, does IOL have to support non-blocking IOLs and some kind of
> > IOLpoll?
>
> nope... you just need to toggle between using a timeout of 0 on the
> cgi, and a timeout of whatever the Timeout value is set to.
>
> something like this (with absolutely no apologies for the gotos):
>
> long timeout;
>
> goto enter;
> for (;;) {
> rc = ap_bread(fb, buf, sizeof(buf));
> again:
> if (rc <= 0) {
> if (rc == 0) {
> /* done, flush, return */
> }
> if (rc == -1 && errno != EAGAIN) {
> error handling;
> }
> /* next read will block, so flush client now */
> rc = ap_bflush(conn->client);
> /* deal with rc errors here */
> /* block reading until timeout */
> timeout = value of Timeout for this request;
> ap_bsetopt(fb, BO_TIMEOUT, &timeout);
> rc = ap_bread(fb, buf, sizeof(buf));
> enter:
> timeout = 0;
> ap_bsetopt(fb, BO_TIMEOUT, &timeout);
> goto again;
> }
> loop calling ap_bwrite(conn->client, buf, rc) until it's all written;
> }
Err. OK. Its far from clear that that's what the code does now (in fact,
seems to me it doesn't, but that's probably coz its expecting an alarm
that won't happen). Nominally the timeout support is there already (in
that you can do a setopt on it) but I'll wager it doesn't actually
work...
Darn. I'd mostly implemented something, too (I realised that all you had
to do was wait for read to be ready, not have the whole poll/select
machinary but I'd forgotten about the timeout. Dang).
BTW, this although we've managed to slide past it this time, I do have
this feeling of impending doom wrt to poll/select and IOL.
> > Until this happens, CGI doesn't work, and that's a rather large hole in
> > MPM.
>
> we still need process abstraction to help CGIs...
Different issue, IMO.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: IOL and send_fb
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 16 Aug 1999, Ben Laurie wrote:
> Dean Gaudet wrote:
> >
> > On Mon, 16 Aug 1999, Ben Laurie wrote:
> >
> > > OK, I sort of get this, but... it seems to me that this won't timeout
> > > CGIs (which it should, right?) ... if the CGI never says anything, we
> > > hang forever, no?
> >
> > before the blocking read the loop sets the timeout on the CGI BUFF back
> > to the appropriate amount (which can be different from the timeout for
> > the client now, btw).
>
> I've just realised that timeout == 0 means don't wait at all, not wait
> forever. Given this, isn't the non-blocking thing redundant (i.e.
> timeout == 0 implies nonblock)?
right, you don't need ap_setnonblock or whatever it's called... because
timeout controls that now.
yeah the timeout values are documented in the ap_iol.h file but not in the
buff.h file, oops.
Dean
Re: IOL and send_fb
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Mon, 16 Aug 1999, Ben Laurie wrote:
>
> > OK, I sort of get this, but... it seems to me that this won't timeout
> > CGIs (which it should, right?) ... if the CGI never says anything, we
> > hang forever, no?
>
> before the blocking read the loop sets the timeout on the CGI BUFF back
> to the appropriate amount (which can be different from the timeout for
> the client now, btw).
I've just realised that timeout == 0 means don't wait at all, not wait
forever. Given this, isn't the non-blocking thing redundant (i.e.
timeout == 0 implies nonblock)?
> > Seems to me that the non-blocking and timeout requirements of old are
> > confusing the issue. What we want is that both reads and writes time
> > out, and block until they do, right? Or am I missing something?
>
> The only reason the non-blocking bit is in there is so that the code
> can bflush the client socket before blocking on the read... that
> way CGIs which stutter their output will stutter all the way to the
> client.
Got it. I think.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: IOL and send_fb
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 16 Aug 1999, Ben Laurie wrote:
> OK, I sort of get this, but... it seems to me that this won't timeout
> CGIs (which it should, right?) ... if the CGI never says anything, we
> hang forever, no?
before the blocking read the loop sets the timeout on the CGI BUFF back
to the appropriate amount (which can be different from the timeout for
the client now, btw).
> Seems to me that the non-blocking and timeout requirements of old are
> confusing the issue. What we want is that both reads and writes time
> out, and block until they do, right? Or am I missing something?
The only reason the non-blocking bit is in there is so that the code
can bflush the client socket before blocking on the read... that
way CGIs which stutter their output will stutter all the way to the
client.
Dean
Re: IOL and send_fb
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Mon, 16 Aug 1999, Ben Laurie wrote:
>
> > Errr ... why? AFAICS the loop you outline below has an ap_bread that
> > never gets called. It sets the timeout to zero and then back to the
> > timeout value, and reads from the CGI, then repeats.
> >
>
> yeah the loop has bugs.
>
> > Why not just set the timeout value once and be done with it?
>
> because you want a non-blocking read, which you need to be 0. then when
> you get an EAGAIN you want to bflush the client, and then you want
> to block until the CGI read completes -- and to block you want to set
> the timeout.
OK, I sort of get this, but... it seems to me that this won't timeout
CGIs (which it should, right?) ... if the CGI never says anything, we
hang forever, no?
Seems to me that the non-blocking and timeout requirements of old are
confusing the issue. What we want is that both reads and writes time
out, and block until they do, right? Or am I missing something?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: IOL and send_fb
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 16 Aug 1999, Ben Laurie wrote:
> Errr ... why? AFAICS the loop you outline below has an ap_bread that
> never gets called. It sets the timeout to zero and then back to the
> timeout value, and reads from the CGI, then repeats.
>
yeah the loop has bugs.
> Why not just set the timeout value once and be done with it?
because you want a non-blocking read, which you need to be 0. then when
you get an EAGAIN you want to bflush the client, and then you want
to block until the CGI read completes -- and to block you want to set
the timeout.
try this:
timeout = 0;
ap_bsetopt(fb, BO_TIMEOUT, &timeout);
for (;;) {
rc = ap_bread(fb, buf, sizeof(buf));
if (rc <= 0) {
if (rc == 0) {
done, flush, return;
}
if (rc == -1 && errno != EAGAIN) {
error handling, return;
}
/* next read will block, so flush the client now */
rc = ap_bflush(conn->client);
/* deal with rc errors here */
timeout = value of Timeout for this request;
ap_bsetopt(fb, BO_TIMEOUT, &timeout);
rc = ap_bread(fb, buf, sizeof(buf));
if (rc <= 0) {
if (rc == 0) {
done, flush, return;
}
error handling, return;
}
timeout = 0;
ap_bsetopt(fb, BO_TIMEOUT, &timeout);
}
loop writing rc bytes from buf;
}
Dean
Re: IOL and send_fb
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Sun, 15 Aug 1999, Ben Laurie wrote:
>
> > There's this rather optimistic note in MPM that suggests we reimplement
> > send_fb (or, more particularly, send_fb_length). Snag is, it used to use
> > select(). Someone thinks it might now use poll(). But it can't really
> > use either, because of IOL. It also tries to use non-blocking I/O.
> > Again, IOL is a bit of a barrier. Does anyone have an ingenious plan
> > here, or is it simply a matter of extending IOL until this can work?
> > That is, does IOL have to support non-blocking IOLs and some kind of
> > IOLpoll?
>
> nope... you just need to toggle between using a timeout of 0 on the
> cgi, and a timeout of whatever the Timeout value is set to.
Errr ... why? AFAICS the loop you outline below has an ap_bread that
never gets called. It sets the timeout to zero and then back to the
timeout value, and reads from the CGI, then repeats.
Why not just set the timeout value once and be done with it?
If "again:" was supposed to appear above the ap_bread (making it
redundant), then what is the point? Read half the CGI output with a
timeout and half not? Huh? I'm confused.
>
> something like this (with absolutely no apologies for the gotos):
>
> long timeout;
>
> goto enter;
> for (;;) {
> rc = ap_bread(fb, buf, sizeof(buf));
> again:
> if (rc <= 0) {
> if (rc == 0) {
> /* done, flush, return */
> }
> if (rc == -1 && errno != EAGAIN) {
> error handling;
> }
> /* next read will block, so flush client now */
> rc = ap_bflush(conn->client);
> /* deal with rc errors here */
> /* block reading until timeout */
> timeout = value of Timeout for this request;
> ap_bsetopt(fb, BO_TIMEOUT, &timeout);
> rc = ap_bread(fb, buf, sizeof(buf));
> enter:
> timeout = 0;
> ap_bsetopt(fb, BO_TIMEOUT, &timeout);
> goto again;
> }
> loop calling ap_bwrite(conn->client, buf, rc) until it's all written;
> }
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: IOL and send_fb
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 15 Aug 1999, Ben Laurie wrote:
> There's this rather optimistic note in MPM that suggests we reimplement
> send_fb (or, more particularly, send_fb_length). Snag is, it used to use
> select(). Someone thinks it might now use poll(). But it can't really
> use either, because of IOL. It also tries to use non-blocking I/O.
> Again, IOL is a bit of a barrier. Does anyone have an ingenious plan
> here, or is it simply a matter of extending IOL until this can work?
> That is, does IOL have to support non-blocking IOLs and some kind of
> IOLpoll?
nope... you just need to toggle between using a timeout of 0 on the
cgi, and a timeout of whatever the Timeout value is set to.
something like this (with absolutely no apologies for the gotos):
long timeout;
goto enter;
for (;;) {
rc = ap_bread(fb, buf, sizeof(buf));
again:
if (rc <= 0) {
if (rc == 0) {
/* done, flush, return */
}
if (rc == -1 && errno != EAGAIN) {
error handling;
}
/* next read will block, so flush client now */
rc = ap_bflush(conn->client);
/* deal with rc errors here */
/* block reading until timeout */
timeout = value of Timeout for this request;
ap_bsetopt(fb, BO_TIMEOUT, &timeout);
rc = ap_bread(fb, buf, sizeof(buf));
enter:
timeout = 0;
ap_bsetopt(fb, BO_TIMEOUT, &timeout);
goto again;
}
loop calling ap_bwrite(conn->client, buf, rc) until it's all written;
}
> Until this happens, CGI doesn't work, and that's a rather large hole in
> MPM.
we still need process abstraction to help CGIs...
Dean