httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@opengroup.org>
Subject Re: sfio (was: Missing headers for small requests? )
Date Fri, 13 Jun 1997 15:47:37 GMT
Randy Terbush <randy@zyzzyva.com> wrote:

> > Randy Terbush wrote:
> >
> > > [Still digging through the backlog]
> > > 
> > > Not sure if this has been mentioned, but the fact that Perl 5.004 
> > > now has an sfio option would make me lean toward using that if we 
> > > can to reduce redundant code.
> > > 
> > 
> > Does the sfio-stuff work in Perl? The docs seem to suggest it very
> > experimental at this point (Perl's IO abstraction)
> 
> >From what I am reading in the mod_perl discussions, I assume that 
> it does. Doug or Rob should probably comment on it's stability.

>From what I've seen the sfio/Perl combo is quite stable.  mod_perl
uses sfio to hook up STDIN and STDOUT to the client, so perl's
built-in print() and read() functions work as they do under CGI.  This
is no longer required as gaps in tie'd filehandles were filled in
before 5.004.  sifo-enabled Perl is a requirement for mod_fastcgi.
Between the two, over the past several months I've seen/heard from
people running it on many flavors of unix without any troubles.  There
were are few people who had build troubles with "sfio-oct95", but
those seem to have gone away with "sfio97".

A while back I put this together, which is derived from PerlIO:
http://www.osf.org/~dougm/apache-2.0/apacheio.html

The basic idea is all the b*() functions are replaced by ApacheIO_
macros (that look like functions).  And r->connection->client is made
opaque with ApacheIO* instead of BUFF*, again another #define.  The
idea was, at configure time, -DUSE_APACHE_FOO would bootstrap the
underlying i/o system via these ApacheIO_ defines.  The default being
the current buff mechansim, other options include sfio.  This was nice
for me, since I didn't have to lay a finger on buff.c.  After talking
with Alexi and looking closer at buff.c, I see no reason not to tie
sfio directly into the current buff mechanism, which should actually
be less work.  The question is, should sfio be a requirement or an
option?  

This is another piece needed for DCE, i/o needs to pass thru the RPC
interface, not the socket connection that is normally established.  I'm
actually experimenting with an sfio-enabled apache as we speak.  The
basic idea is, the lowest-level read and write calls in buff.c
are replaced with sfread and sfwrite.  By default, the input and output
streams are tied the `ApacheSFIO_t' discipline which hooks back into the
current low-level saferead/read, bwrite/writev/write, etc.  The dce
module can pop this discipline off the stack, change the read/write
function pointers to the rpc interface, then push it back.  I have not
experimented with more than one discipline on either stack, but when I
do, I'll share my experience.

-Doug

Mime
View raw message