You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Robert S. Thau" <rs...@ai.mit.edu> on 1996/05/30 18:02:17 UTC

YA threaded snapshot.

I've just put up yet another snapshot of my threaded server.  This one
has been running since Sunday in pretty much its current form on my
SunOS main server; it has also passed smoke tests on Irix, Linux,
Digital Unix, and HP-UX, but has known problems on Solaris (see below
if you're a Solaris guru and want to take a crack at it).  The
snapshot is at <ftp://ftp.ai.mit.edu/pub/users/rst/apache-XX.tar.gz>.

This version has the following improvements over the last one:

1) Based on a more recent snapshot of the 1.1 dev tree (though the
   patch frenzy of the past few days has not yet been folded in; I
   hope to resynch after the next public beta).

2) Fixed a couple of really stooooopid mistakes in the low-level I/O
   handling, one of which probably accounts for at least some of the
   performance problems RobH noted.

3) Highly experimental chunked encoding support (modulo my possible
   misreadings of the spec, and as per HTTP/1.1 draft -03, *not* -04;
   it only sends chunked response bodies on persistent connections,
   and does not implement the draft-04 rules on default persistence
   with 1.1 clients).  I did this to gain a little experience in
   dealing with sfio and sfio disciplines --- specifically, sfio
   voodoo is used to produce a stream which adds the chunk-sizes onto
   data written on it before piping it out the file descriptor, so we
   can get chunked output from CGI, SSI, directory listings, etc.

   Don't use this as a model for anything else yet --- there are
   probably less kludgy ways to do a lot of what I did, and it'll be a
   better model for other sorts of work after the cleanup (never mind
   the likelihood of out-and-out bugs).  Still, it's at least an
   existence proof.

As before, don't try to do too much with this before reading and
understanding the caveats in the README.  For those who'd like to know
what they're getting into, brief summaries follow:

1) StartServers should probably be adjusted downwards from whatever
   you've set it to; other config-file parameters may also need
   adjustment for best results.
  
2) Configuration is a mess --- three packages, with three different ad
   hoc configuration schemes.  Paging Tom Tromey...

3) The following are known *not* to work:  -DMAXIMAL_DNS, -DSTATUS,
   IdentityCheck, mod_proxy.  Many other things have not been tried;
   stuff which makes excessive use of MAX_STRING_LEN buffers may be
   trouble.  (I've already had to deal with mod_includes).

4) rprintf and r->bytes_sent are back.  The use of bgetopt(..., BO_BYTECT)
   for r->bytes_sent is gone.

5) Name service works through DNS and DNS *only*; if you're using NIS,
   or you have VirtualHost declarations for localhost (which works
   through /etc/hosts) they won't work.
  
6) GDB copes with a threaded target better than you might expect, but
   it ain't perfect.  The incantation "handle SIGUSR1 nostop noprint"
   helps much on platforms where sigstack is used to kick off new threads;
   see the README for other hints.

The README includes a couple of other hints and caveats for those
porting to new systems, or otherwise motivated to hack the code.

Share and enjoy...

rst

PS --- the Solaris problem is that for no apparent reason, the
   select() in io_check() inside athreads.c gets a SIGSEGV.  (The
   io_check() routine is clearly the problem --- if it's diked out,
   the scheduler test, which doesn't require I/O support, runs fine).
   To make matters more confusing, a slightly earlier version of
   athreads, with no obviously relevant differences in that particular
   routine, *does* pass its own tests on Solaris.  I'm still trying to
   track this down.

   If any Solaris guru wants to take a crack at it independantly, you
   *don't* need to compile the whole web server to start debugging
   this; the athread_test program, which requires no support from
   outside the "athreads" directory --- in particular, no sfio ---
   will do fine as a test case.

   

Restart kills on Solaris 2.5

Posted by Michael Smith <mj...@cursci.co.uk>.
On Solaris 2.5 (apache 1.1b4) I often find that attempting to restart
the server (kill -1) actually kills it.  I don't know about 1.1b3 but
this replaces the problem in 1.1b2 when killing sometimes only killed
the parent httpd and not its children.

Has anyone else found this on similar or different architectures?

Michael Smith

Re: YA threaded snapshot.

Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Thu, 30 May 1996, Robert S. Thau wrote:

[...]

> 3) Highly experimental chunked encoding support (modulo my possible
>    misreadings of the spec, and as per HTTP/1.1 draft -03, *not* -04;
>    it only sends chunked response bodies on persistent connections,
>    and does not implement the draft-04 rules on default persistence
>    with 1.1 clients).  I did this to gain a little experience in
>    dealing with sfio and sfio disciplines --- specifically, sfio
>    voodoo is used to produce a stream which adds the chunk-sizes onto
>    data written on it before piping it out the file descriptor, so we
>    can get chunked output from CGI, SSI, directory listings, etc.

I've downloaded this, and it complies and runs seemingly fine, but
FWIW, I think you did misread the spec.

Going by the example parsing code in section 23.3.6, not by the BNF
itself (but that seems to agree), it says (shortening it a bit):

       read chunk-size and CRLF
       while (chunk-size > 0) {
          read chunk-data and CRLF
          read chunk-size and CRLF
       }

The server doesn't appear to send the CRLF after chunk-data. It goes
straight from the data to the next chunk-size. Hmm. Of course, I could
be wrong. Happens often enough.

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/
 
      "War does not determine who is right, only who is left."