httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henrik Vendelbo" <hvende...@bluprints.com>
Subject Sv: Thread safe functions in Apache/APR
Date Sun, 17 Oct 1999 13:32:07 GMT
+1 Good Stuff

----- Original Message ----- 
From: Ryan Bloom <rbb@raleigh.ibm.com>
To: <new-httpd@apache.org>
Sent: Saturday, October 16, 1999 4:12 PM
Subject: Thread safe functions in Apache/APR


> 
> I have finished making APR thread-safe.  I'm committing those changes now.
> However, in doing this, I realized that we have actually not made these
> functions thread-safe.  We have simply hidden things.  The problem is that
> on some platforms, it is conceivable that some of the functions we have
> "locked" will call other functions, which are not thread-safe, and which
> are not "protected".  In fact, there are a lot of papers that say what we
> are doing is a bad idea.  I happen to agree with them.  This solution also
> only works within APR.  Other projects, like Apache, will need to find
> their own way to implement their own mutex locking.  I do not like this
> idea.
> 
> So, my solution.  We leave what I have just committed as a stop-gap
> solution.  It will work on 99% of the platforms.  Over time, we replace
> all of the non-thread-safe functions in POSIX with thread-safe versions
> which we will write.  I am assuming all of these will go into APR.  This
> solves the problem for ALL projects wishing to use APR, and it is cleaner
> and we know it will always work.  This is also a well defined project,
> because POSIX determines which functions are not thread-safe for us.
> There is need to do much investigation to find them.
> 
> I will begin working on this ASAP, and it will most likely take a while to
> finish.  The first function I will be writing, is ap_strtok.  This is
> because Apache needs this functions, and it is NOT thread-safe at all.
> This work will go much faster, if there is a C Run-Time that is under a
> BSD-ish License.  Is FreeBSD using glibC?  I hope not, but you never know.
> 
> If anybody has any objections, let me know.  Otherwise, you can expect to
> see some new basic functions added to APR over the next few weeks.
> 
> Ryan
> 
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd 
> RTP, NC 27709 It's a beautiful sight to see good dancers 
> doing simple steps.  It's a painful sight to
> see beginners doing complicated patterns. 
> 
> 


Mime
View raw message