httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: threads
Date Sat, 17 Aug 1996 00:27:02 GMT
On Sat, 17 Aug 1996, Ben Laurie wrote:

> I've also been thinking about this (not surprisingly, since I've been poking
> at Win32 threads), and it seems to me that we do need the compatibility layer,
> however, I'm not sure that there's any need to look further than rsthreads.
> That is, the compatibility layer may as well be the rsthreads API.
> Certainly what I've done so far of the Win32 stuff suggests that this is the
> right way round to do it, but I'll comment further when I've done more.

Could be. I haven't looked exactly at what all of the thread packages do
(I don't have access to Win32, really, so I don't even have the
possibility of looking at that).  There are, however, some differences.
RSThread per-thread data, for example, can be of any size - you could
store a structure in there, for example. POSIX per-thread keys (as they're
called), though, can only store a pointer. There are probably other
similar quirks, where we may have to reduce the functionality of rsthreads
to the lowest common demominator of the functionality we want to make
available to users. 

We should probably make a list of what thread-related functions (this
includes non-thread related, but thread-unsafe stuff) should be accessable
by users. Certainly per-thread data and mutexes are good candidates. We'd
need to think about whether or not we wanted modules to be able to have
their own threads (it could be a useful feature, but it also means we need
to do more work in mapping all the thread stuff). DNS access, certainly. 
Some of these might even have to be per-OS dependent (Solaris'
gethostbyname_r and related functions, for example).

-- Alexei Kosut <>            The Apache HTTP Server

View raw message