dougm at opengroup
Jun 13, 1997, 8:47 AM
Post #8 of 10
(722 views)
Permalink
|
|
Re: sfio (was: Missing headers for small requests? )
[In reply to]
|
|
Randy Terbush <randy [at] zyzzyva> 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
|
