Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 2613 invoked by uid 6000); 16 Apr 1998 19:31:44 -0000 Received: (qmail 2606 invoked from network); 16 Apr 1998 19:31:42 -0000 Received: from twinlark.arctic.org (204.62.130.91) by taz.hyperreal.org with SMTP; 16 Apr 1998 19:31:42 -0000 Received: (qmail 12701 invoked by uid 500); 16 Apr 1998 19:34:49 -0000 Date: Thu, 16 Apr 1998 12:34:48 -0700 (PDT) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: NSPR/multithreading stuff In-Reply-To: Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Thu, 16 Apr 1998, Dean Gaudet wrote: > Well we can decide on it, but it shouldn't be locked in stone. I'm > particularly enamoured of the POSIX API given that it is an existing > standard and already implemented in many places. There may even exist a > WIN32 port of it, dunno. It should serve as a model at any rate. Oh yeah, additional support for this reasoning: third party libraries are more likely to support pthreads than something we develop on our own. If we were to lock ourselves into, say, NSPR, and Big Database Vendor has a client library which is pthread friendly, but NSPR's handling of thread specific data or mutexes, or anything is compatible with pthreads... then we lose bad. Well, our users lose, module writers lose. And so on. What does threaded perl run on? Rasmus, you've mentioned before that there is a dearth of multithread support in third-party libraries. Any updates on that? If there's even one db vendor clued enough to provide multithread support then I think it would be a good thing for us to try to accomodate that "forward thinking". Eventually there'll be a free pthread-safe resolver too I'm sure, and that would save us some work. It just makes sense for us to adopt a common standard in this area. Dean