You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <st...@raleigh.ibm.com> on 2000/06/22 19:46:57 UTC
APR_EOF?
Take a look at this snip of code from read_with_errors...
if (rv != APR_SUCCESS) {
do {
rv = iol_read(fb->iol, buf, nbyte, bytes_read);
} while (rv == EINTR && !(fb->flags &B_EOUT));
}
if (rv == APR_SUCCESS && *bytes_read == 0) {
fb->flags |= B_EOF;
}
Notice we are setting B_EOF if APR_SUCCESS and no bytes read. I prefer this behavious to
checking for APR_EOF. Do we have agreement on how APR signals EOF conditions? Notice
also that iol_read can be reading from a socket which implies ap_recv() must do the right
thing as well.
On a related topic, is there any reason why we can't consolidate the ap_read code across
platforms? ap_read must:
1. handle the ungetchar
2. handle reads (non-blocking, non-blocking with timeouts and blocking)
3. buffered i/o
4. 1 thru 3 for both files and pipes
Most of this code is identical across Unix and Windows which implies we should create a
common ap_read() implementation which calls a platform specific os_read_with_timeout().
os_read_with_timeout() is where the platform specific code resides.
os_read_with_timeout() would need to know if it is handling a pipe or a file. Right now,
each platform is handling the ungetchar, buffered reads, etc. differently, which is not
good.
Why not combine socket i/o with file i/o, i.e., make ap_read() handle sockets, pipes and
files and eliminate entirely ap_recv()? Ditto the ap_write() and ap_send.
Bill
Re: APR_EOF?
Posted by Jeff Trawick <tr...@ibm.net>.
> From: "Bill Stoddard" <st...@raleigh.ibm.com>
> Date: Thu, 22 Jun 2000 13:46:57 -0400
>
> Take a look at this snip of code from read_with_errors...
>
> if (rv != APR_SUCCESS) {
> do {
> rv = iol_read(fb->iol, buf, nbyte, bytes_read);
> } while (rv == EINTR && !(fb->flags &B_EOUT));
> }
> if (rv == APR_SUCCESS && *bytes_read == 0) {
> fb->flags |= B_EOF;
> }
>
> Notice we are setting B_EOF if APR_SUCCESS and no bytes read. I prefer this behavious to
> checking for APR_EOF. Do we have agreement on how APR signals EOF conditions? Notice
> also that iol_read can be reading from a socket which implies ap_recv() must do the right
> thing as well.
We all went off on the related topic, which was much more fun. The
immediate need is to handle the APR_EOF issue in the current code, and
(I assert) to handle it the same for sockets, pipes, and files to
allow the existing iols to work cleanly.
A few days ago, a few folks spoke up in favor of APR_EOF for
files/pipes. That is still fine with me.
I'm not fundamentally opposed to rv==0/*nbytes==0 for eof; I simply
prefer APR_EOF.
I'm uncomfortable with the notion that we get non-zero rv as well as
non-zero *nbytes; hopefully that won't pop up again.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APR_EOF?
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
Forget for now my speculation that maybe we could combine sockets with pipe/file i/o. Just
focus on sharing pipe/file code between platforms.
> > On a related topic, is there any reason why we can't consolidate the
> > ap_read code across platforms? ap_read must:
> >
> > 1. handle the ungetchar
> > 2. handle reads (non-blocking, non-blocking with timeouts and blocking)
> > 3. buffered i/o
> > 4. 1 thru 3 for both files and pipes
> >
> > Most of this code is identical across Unix and Windows which implies
> > we should create a common ap_read() implementation which calls a
> > platform specific os_read_with_timeout(). os_read_with_timeout() is
> > where the platform specific code resides. os_read_with_timeout() would
> > need to know if it is handling a pipe or a file. Right now, each
> > platform is handling the ungetchar, buffered reads, etc. differently,
> > which is not good.
>
> I just looked at the ap_read code. Most of it is not common across
> platforms.
Indeed. ap_read() semantics are different for each platform, which is precisely the
problem.
> One of the reasons that we have re-written this code, is so
> that Windows can use their native functions.
os_read_with_timeout() implements the lowlevel platform specific read with timeout. All
very platform specific. The code to handle ungetchar, i/o buffering, etc can all be
identical. Watch what I do with ap_read on Windows in the next week or so (it doesn't do
timeout now). The only crufty thing that comes to mind is the implementation of ap_file_t.
Yes, it would need to include #ifdef YOUR_PLATFORM whatnot. This may be a worthwhile
tradeoff in certain circumstances if it helps keep APR semantics the same across multiple
implementations. Right now it's all over the floor.
Bill
Re: APR_EOF?
Posted by rb...@covalent.net.
> On a related topic, is there any reason why we can't consolidate the
> ap_read code across platforms? ap_read must:
>
> 1. handle the ungetchar
> 2. handle reads (non-blocking, non-blocking with timeouts and blocking)
> 3. buffered i/o
> 4. 1 thru 3 for both files and pipes
>
> Most of this code is identical across Unix and Windows which implies
> we should create a common ap_read() implementation which calls a
> platform specific os_read_with_timeout(). os_read_with_timeout() is
> where the platform specific code resides. os_read_with_timeout() would
> need to know if it is handling a pipe or a file. Right now, each
> platform is handling the ungetchar, buffered reads, etc. differently,
> which is not good.
I just looked at the ap_read code. Most of it is not common across
platforms. One of the reasons that we have re-written this code, is so
that Windows can use their native functions. The types are different
throughout these functions, as are the function calls and return
values. There is error checking in the Windows code that doesn't exist or
need to exist in the Unix side. I am against trying to combine this code
right now. It will just make the code that much harder to read and
understand.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: APR_EOF?
Posted by Jeff Trawick <tr...@ibm.net>.
> From: rbb@covalent.net
> Date: Thu, 22 Jun 2000 11:10:49 -0700 (PDT)
>
> > > Windows files are not the same as Windows sockets. Ditto for OS/2 and
> > > BeOS. Because Unix is the only platform that has files and sockets that
> > > are equivalent, it is not possible to combine the two types or any
> > > functions that have to deal with the two types. Not possible is a bit
> > > strong, obviously it is possible, however it removes type checking at
> > > compile time, and is generally a bad idea. This was all covered way back
> > > when, when APR was first designed and implemented.
> >
> > This would be handled by Bill's os_read_with_timeout(), which knows
> > whether it is a pipe or file or socket and thus can use the correct
> > syscall.
>
> How does it know? Are we passing a void * in? Are we combining the two
> types? I sure hope we aren't even thinking about combining sockets and
> files in APR. If we don't combine them, then this can't be
> done. os_read_with_timeout can help us merge the ap_read code for unix
> and windows, but it can't help us merge files and sockets.
os_read_with_timeout() needs to know a few key pieces of
information in addition to normal parameters to a read:
. handle to pipe/file/socket/whatever
. indicator of whether it is pipe/file/socket/whatever
. timeout value (whether timeout is part of this info or part of
parmlist to os_read_with_timeout() is not so important to the
overall discussion)
. eof indicator (if this is here, then os_read_with_timeout() can take
care of that detail)
At this point, os_read_with_timeout() can handle sockets, files, and
pipes.
Move up a level to where ap_read() and ap_recv() (and buffering
and ungetc) live...
If you add ungetchar and the buffering information to the key
file/pipe/socket representation (whether or not buffered, ptr to
buffer, offset within buffer, buffer lock, direction), then ap_read()
and ap_recv() could be shims which call a common read function (call
it common_read for now) which can handle buffering and ungetchar but
which doesn't have to know about timeouts and whether it is socket or
pipe or file or what syscall is used to read from them.
ap_file_t and ap_socket_t would embed this other structure.
Note that adding buffering here in common_read implies we do the same
cleanup for write operations, because a buffered read when we've been
writing needs to flush the buffer first.
Besides less code, this would help ensure common semantics across
platforms as well as among files, pipes, and sockets. It would
provide buffered reading of sockets in APR and ungetc on sockets too
(no claim that this is important).
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APR_EOF?
Posted by rb...@covalent.net.
> > Windows files are not the same as Windows sockets. Ditto for OS/2 and
> > BeOS. Because Unix is the only platform that has files and sockets that
> > are equivalent, it is not possible to combine the two types or any
> > functions that have to deal with the two types. Not possible is a bit
> > strong, obviously it is possible, however it removes type checking at
> > compile time, and is generally a bad idea. This was all covered way back
> > when, when APR was first designed and implemented.
>
> This would be handled by Bill's os_read_with_timeout(), which knows
> whether it is a pipe or file or socket and thus can use the correct
> syscall.
How does it know? Are we passing a void * in? Are we combining the two
types? I sure hope we aren't even thinking about combining sockets and
files in APR. If we don't combine them, then this can't be
done. os_read_with_timeout can help us merge the ap_read code for unix
and windows, but it can't help us merge files and sockets.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: APR_EOF?
Posted by Jeff Trawick <tr...@ibm.net>.
> From: rbb@covalent.net
> Date: Thu, 22 Jun 2000 10:48:47 -0700 (PDT)
>
> > Why not combine socket i/o with file i/o, i.e., make ap_read() handle
> > sockets, pipes and
> > files and eliminate entirely ap_recv()? Ditto the ap_write() and
> > ap_send.
>
> Windows files are not the same as Windows sockets. Ditto for OS/2 and
> BeOS. Because Unix is the only platform that has files and sockets that
> are equivalent, it is not possible to combine the two types or any
> functions that have to deal with the two types. Not possible is a bit
> strong, obviously it is possible, however it removes type checking at
> compile time, and is generally a bad idea. This was all covered way back
> when, when APR was first designed and implemented.
This would be handled by Bill's os_read_with_timeout(), which knows
whether it is a pipe or file or socket and thus can use the correct
syscall.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APR_EOF?
Posted by rb...@covalent.net.
> Why not combine socket i/o with file i/o, i.e., make ap_read() handle
> sockets, pipes and
> files and eliminate entirely ap_recv()? Ditto the ap_write() and
> ap_send.
Windows files are not the same as Windows sockets. Ditto for OS/2 and
BeOS. Because Unix is the only platform that has files and sockets that
are equivalent, it is not possible to combine the two types or any
functions that have to deal with the two types. Not possible is a bit
strong, obviously it is possible, however it removes type checking at
compile time, and is generally a bad idea. This was all covered way back
when, when APR was first designed and implemented.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------