httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)
Date Thu, 18 Mar 1999 15:08:27 GMT

> I'm really on a fence about this. A2 was "supposed" to be such a hybrid,
> one in which if the OS didn't support threads, it could still run. I
> think we'd all still like that ideal. However, if there comes a design
> issue which says "by doing this, we really significantly limit what
> we can do, or how fast we can do this" then I think it's time to rethink
> that.

I think it is important to note that as far as I know, there is nothing
that has been designed such that we MUST have threads.  It ahs been coded
so that we need threads, because we didn't want to bite off too much in
the first implementation, but it was designed so that with a few #defines
and well placed #ifdefs, it should be VERY easy to go non-threaded,
without ANY performance issues in the threaded server.  Notice, I said
should, not would.  BIG difference.
> I guess one analogy, which I brought up before, might be helpful. Right
> now, A1.3 (when did _that_ start? :) ) supports file-based, SysV-shared-

Gotta love those shortcuts :)

> mem-based and mmap-based scoreboards. Without a doubt, using "shared
> memory" (generic shared mem, ie: SysV shmget and mmap) is the way to
> go, but we still allow for file-based scoreboards. I have no idea
> if that even works anymore, but it's certainly not optimal. If we decided
> that we "needed" to drop file-based scoreboards, then that may be a
> valid decision and one that makes sense. Now let's say that we design
> Apache around the existance of mmap(). Now that's a whole different
> game. Not all OSs have a mmap, or one reliable enough to base the
> operation of the server on. Or maybe it's SysV shared memory implementation
> is better. Or something else.

If the file-based scoreboard stuff works in the process based server (?)
then it should work in the hybrid server.  We haven't tested it, but
hopefully we'll get to it someday.  I think we should leave it in, because
again, the goal IMO should be that if a platform needs it, with a few
smart #defines, they can get a process based Apaceh out of the A2.0 code

> So is the thread-vs-no_thread issue closer to dropping file-based scoreboards
> or requiring mmap()? I _think_ it's closer to the former. I don't
> see anything in the code that requires threads, but just code that
> is "better" with threads. (of course, that's not quite right, because
> if you try to build apache-apr right now without pthreads installed,
> it'll fail. But I'm talking actual code-base).

There is NOTHING in the code that absolutely requires threads, as soon as
we abstract out the accept loop logic.  We are always linking against the
pthreads library, but only because we are lazy people, and we wanted to
get the threaded server working before we started making it truly
configurable.  Sorry, we'll go hide our heads in shame now :)

> As far as whether there are pieces that _should_ be required to use
> threads, well, I feel unqualified to say.

I don't think that there are ANY pieces that should be required to use
threads.  With a good way to use A1.3 modules (the module daemon is an
okay start I think) and abstracting out the accept loop stuff (we're
getting there), we have a very good process based server that has never
been tested.  Again, we are getting to the testing, but we have other
items on our plates right now.


Ryan Bloom
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.	

View raw message