Received: by taz.hyperreal.com (8.7.5/V2.0) id JAA11888; Tue, 6 Aug 1996 09:32:30 -0700 (PDT) Received: from life.ai.mit.edu by taz.hyperreal.com (8.7.5/V2.0) with SMTP id JAA11877; Tue, 6 Aug 1996 09:32:27 -0700 (PDT) Received: from volterra.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for new-httpd@hyperreal.com id AA14814; Tue, 6 Aug 96 12:32:22 EDT From: rst@ai.mit.edu (Robert S. Thau) Received: by volterra.ai.mit.edu (8.6.12/AI-4.10) id MAA17533; Tue, 6 Aug 1996 12:31:06 -0400 Date: Tue, 6 Aug 1996 12:31:06 -0400 Message-Id: <199608061631.MAA17533@volterra.ai.mit.edu> To: new-httpd@hyperreal.com Subject: Re: random questions... Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Not as I understand it. It would be a) difficult and b) pointless to maintain non-threaded versions of stuff that uses threading. I think that at the very least rsthreads (or equivalent) will be required. Since rsthreads is exceedingly portable I can't see that this is a problem. I'm not sure I agree... look at the LDAP reference software. The code is written in a "thread-aware" style. On machines without thread support, it's still supported, by means of a file which provides trivial implementations (single-thread case only) of the functions used by the code. Such "null threading" doesn't eliminate the dependancies completely, but it makes it perfectly manageable to build non-threaded and threaded versions of their server from the same code base without drowning in #ifdefs. rst