httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: NSPR/apache
Date Tue, 21 Apr 1998 01:12:57 GMT

I sent one of Dean's messages to a friend at Netscape, one of the NSPR
developers.  His response: (I'm going to try and get him more closely
involved with the discussion)

>Date: Mon, 20 Apr 1998 17:43:18 -0700
>From: (Mike Belshe)
>X-Mailer: Mozilla 4.04 [en]C-NSCP  (Win95; U)
>To: Brian Behlendorf <>
>Subject: Re: NSPR/apache
>> >Date: Mon, 20 Apr 1998 14:45:00 -0700 (PDT)
>> >From: Dean Gaudet <>
>> >To:
>> >Subject: pthreads update
>> >X-Comment: Visit for information
>> regarding copyright and disclaimer.
>> >
>> >... Brian convinced me to study NSPR (go to  I did.  I'm
>> >impressed... so I'm probably going to drop my pthread work and switch to
>> >NSPR.  Hopefully in a couple days I'll just check everything into the
>> >apache-2.0 repository and then Mark can benefit from the
>> >thread-specific-data stuff I've discovered and we can proceed with his
>> >start on NSPR.
>> >
>> >Some quick thoughts:
>> >
>> >- NSPR license, it seems reasonable, folks need to agree on it
>> >
>> >- NSPR doesn't build everywhere... but then neither does everything have
>> >pthreads
>Which platforms are trouble?  It should build basically everywhere; I'm not
>surprised to hear about kinks though.  As far as I know it builds on all
>unixes, mac, win95 and nt.
>> >
>> >- NSPR uses pthreads where it's available, so my comments re: database
>> >vendor/3rd party library support are probably all fine.  We may need some
>> >tweaks to NSPR to do this, but we've got source.  (i.e. I think there may
>> >be some issues because NSPR does MxN multiplexing of user threads onto
>> >system threads; we may need to make it happy having other system threads
>> >hanging around which it didn't create... dunno, just a potential problem,
>> >may not even be a problem at all)\
>The MxN multiplexing can be compiled out if you want to use raw pthreads.  On
>some systems, however, you'll note a significant performance loss by doing so
>(IRIX and winnt in particular).
>There is a routine called PR_Attach().  If someone creates a thread via a
>mechanism other than NSPR- they can call PR_Attach() to make it known to
>This will allow you to use NSPR locks, cvars, and all that good stuff from
>within the thread even though it wasn't created by NSPR.
>Hope this helps,

"Optimism is a strategy for making               
a better future." - Noam Chomsky              

View raw message