Thread safe functions in Apache/APR

[Ryan Bloom <rb...@raleigh.ibm.com>]

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.	

Re: Thread safe functions in Apache/APR

[David Reid <ab...@dial.pipex.com>]

Sounds like a good idea.

----- Original Message -----
From: Ryan Bloom <rb...@raleigh.ibm.com>
To: <ne...@apache.org>
Sent: 16 October 1999 15:12
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.
>

Sv: Thread safe functions in Apache/APR

[Henrik Vendelbo <hv...@bluprints.com>]

+1 Good Stuff

----- Original Message ----- 
From: Ryan Bloom <rb...@raleigh.ibm.com>
To: <ne...@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. 
> 
> 

[background] texts on thread safety?

[Peter W <pe...@usa.net>]

At 10:12am Oct 16, 1999, Ryan Bloom wrote:

> 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. 

Pardon my ignorance here, but I would very much appreciate recommendations
for books, papers, URLs, etc., that discuss thread-safe code design. 

Thanks for your advice, and my apologies for the bandwidth.

-Peter