Re: [APR] Universal return syntax

[Dean Gaudet <dg...@arctic.org>]

On Tue, 26 Jan 1999, Rodent of Unusual Size wrote:

> Dean Gaudet wrote:
> > 
> > On Mon, 25 Jan 1999, Rodent of Unusual Size wrote:
> > 
> > > them into return values; this frees errno for use by any
> > > other uses in the call stack
> > 
> > That's false of course.  errno is tainted by any libc call.
> > APR presumably will be using some of libc.
> 
> I dispute the claim that it's false.  Consider routine A calling
> routine B.  Routine B does something that sets errno, detects it,
> and returns -1.  errno is now fair game, and the value may be
> lost and no-one will know why B failed.  If B returned the error,
> even if it just copied errno as its return value, errno's volatility
> would be irrelevant.

That's not what your claim said though.  We're agreeing with each other.

> > > or parallel threads without losing
> > > the condition within the current call stack.
> > 
> > errno has no multithread problems, not sure if you're implying
> > it does or not.
> 
> I'm coming up to speed on threads and am ignorant in this area.
> Are you saying that each thread has its own copy of errno?

Yes.

Dean

> I thought it was a single global and hence susceptible to parallel
> processing stomping on it.
> -- 
> #ken    P-)}
> 
> Ken Coar                    <http://Web.Golux.Com/coar/>
> Apache Group member         <http://www.apache.org/>
> "Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
> 

Re: [APR] Universal return syntax

[Bill Stoddard <st...@raleigh.ibm.com>]

Ben Hyde wrote:
> 
> Bill Stoddard writes:
> >Eeeek! Maybe I missed the discussion... WHY does NSPR implement threads
> >as fibers? Is it because many OS's don't have decent kernel thread
> >implementations?
> 
> People I trust have told me that an NT thread is a very heavy weight
> object, with a substantial memory hit for each one.  So if you write
> applications with many many threads, say Java programs, you want to
> avoid using them.  The existence of fibers in the NT API would seem
> to suggest that somebody at Microsoft wanted something lighter weight
> badly enough to force the OS guys to implement them.
> 
> The only thing I see threads giving us that fibers don't is compiler
> support for thread local storage.

Hummm, call me a skeptic, but I seriously doubt that an NT thread is so
heavy weight that it would become an issue in web server design. An NT
web server with async I/O and completion ports should be able to support
thousands of concurrent clients quite efficiently with its kernel thread
implementation. 

-- 
Bill Stoddard
stoddard@raleigh.ibm.com

Re: [APR] Universal return syntax

[Ben Hyde <bh...@pobox.com>]

Bill Stoddard writes:
>Eeeek! Maybe I missed the discussion... WHY does NSPR implement threads
>as fibers? Is it because many OS's don't have decent kernel thread
>implementations?

People I trust have told me that an NT thread is a very heavy weight
object, with a substantial memory hit for each one.  So if you write
applications with many many threads, say Java programs, you want to
avoid using them.  The existence of fibers in the NT API would seem
to suggest that somebody at Microsoft wanted something lighter weight
badly enough to force the OS guys to implement them.

The only thing I see threads giving us that fibers don't is compiler
support for thread local storage.

  - ben

Re: [APR] Universal return syntax

[Dean Gaudet <dg...@arctic.org>]

On Mon, 1 Feb 1999, Bill Stoddard wrote:

> Eeeek! Maybe I missed the discussion... WHY does NSPR implement threads
> as fibers? Is it because many OS's don't have decent kernel thread
> implementations?

The NT-specific port of NSPR uses NT fibers to implement "NSPR threads"... 
and it uses completion ports.  Both for speed. 

NSPR threads themselves are co-operatively multitasked.  They have a
pthread port which multiplexes userland threads on top of pthreads... the
hybrid model similar to NT's fibers.  But this isn't the only choice, you
can go straight pthreads if you want, or straight userland threads.

Dean

Re: [APR] Universal return syntax

[Bill Stoddard <st...@raleigh.ibm.com>]

Dean Gaudet wrote:
> 
> On Mon, 1 Feb 1999, Ben Hyde wrote:
> 
> > Dean Gaudet writes:
> > >> I'm coming up to speed on threads and am ignorant in this area.
> > >> Are you saying that each thread has its own copy of errno?
> > >
> > >Yes.
> >
> > Argh.  I suspect that each fiber does not have a private copy.  - ben
> 
> Didn't someone respond on this issue already?
> 
> NSPR threads have thread local data -- and they're implemented using
> fibers.  So there's a way to do it.

Eeeek! Maybe I missed the discussion... WHY does NSPR implement threads
as fibers? Is it because many OS's don't have decent kernel thread
implementations?

-- 
Bill Stoddard
stoddard@raleigh.ibm.com

Re: [APR] Universal return syntax

[Dean Gaudet <dg...@arctic.org>]

On Mon, 1 Feb 1999, Ben Hyde wrote:

> Dean Gaudet writes:
> >> I'm coming up to speed on threads and am ignorant in this area.
> >> Are you saying that each thread has its own copy of errno?
> >
> >Yes.
> 
> Argh.  I suspect that each fiber does not have a private copy.  - ben

Didn't someone respond on this issue already? 

NSPR threads have thread local data -- and they're implemented using
fibers.  So there's a way to do it.

Dean

Re: [APR] Universal return syntax

[Ben Hyde <bh...@pobox.com>]

Dean Gaudet writes:
>> I'm coming up to speed on threads and am ignorant in this area.
>> Are you saying that each thread has its own copy of errno?
>
>Yes.

Argh.  I suspect that each fiber does not have a private copy.  - ben