Re: [apache-plusplus] Process model ideas for C++ Apache.

[Dean Gaudet <dgaudet@arctic.org>]

On Fri, 29 May 1998, Michael Anderson wrote:

> are light-weight user-level. Dean's process model paper describes
> fibers as "co-operatively multi-tasked, with context switching
> occuring only at I/O points or at explicit yield points."
> Therefore, the heavy context-switch we are berating does not
> happen! The advantages of fewer threads still exists.

But your point about L1/L2 cache locality still holds... since fibers all
have their own stacks.  You've definately got me thinking about that
now...

> Now for hybrid systems, depending on the implementation, there
> may be a context-switch or not for CVs. The disadvantage could
> be a heavy context-switch; the advantage would then be that the
> multiple functions could be spread across multiple CPUs.

I doubt it'd be a heavy context-switch.  If a fiber blocks itself on a CV,
the kernel-thread running it will go off and do something else.  Then
later when the CV is signalled and the fiber is awakened it's just a light
switch.  *but* it's a potentially cross-cpu switch... when it comes down
to that level of detail, you just gotta have a really good hybrid library.
I doubt NSPR is optimized in this area at all (at least on linux or
freebsd, it may be on OSF/1 or Solaris, which already have optimizations
to deal with this in their own threading libraries I believe). 

> If the performance of these two differing process models is
> roughly equivalent, which benchmarking across different
> threading models would tell us, the differences boil down
> to programming ease vs. features and capabilities. I think
> Ben's comment that a way to switch among process models
> according to the platform and features of the program are
> appropriate.

Definately.  The whole time I've been working with NSPR I've been asking
myself "could we dynamically load NSPR so that we could use any of the
versions available?" 

One of the main reasons I have that concern is that it's in general
impossible to use a SSM or SMM model with third party libraries unless the
thread library is vendor supplied (i.e. solaris' pthreads implementation
is SMM but looks like SMS to the app).  I say this because if a library
does any I/O it has to go through the abstracted I/O layer or it will
block the entire thread/process.

Dean