Re: [llnl-devel] Re: [Freeipmi-devel] kcs byte array model - validation

[Ben Woodard]

On Fri, 2003-12-12 at 00:43, Anand Babu wrote:
> But my concern is,
> +----------------------------------------------------------------------+
> |  On most systems, `malloc' and `free' are not reentrant, because     |
> |  they use a static data structure which records what memory blocks   |
> |  are free.  As a result, no library functions that allocate or free  |
> |  memory are reentrant.  This includes functions that allocate space  |
> |  to store a result.                                                  |
> +----------------------------------------------------------------------+
> 

I think that this may have been true a while back (early to mid 90's)
but ever since multi-threaded programming became popular libc designers
have been forced to make sure that malloc and free are thread safe.
Every OS that I've programmed threaded programs on, didn't have a
problem with malloc and multithreaded code.

In fact the POSIX 1003.1 Base Specifications Issue 6, System Interfaces,
section 2.9.1 specifies that all functions are thread safe with the
exception of a short enumerated list and neither malloc or free are on
that list.

Now with regards to calling malloc within a signal handler that is
another story. I believe that that is best documented around though I
believe that it will still work under linux and there is an autoconf
test to test if that can be done on that OS. 

> This may be true, with respect to signal handlers and call-back
> procedures. But I'm skeptic about malloc usage inside library. Because
> malloc, free uses static references inside, there is no way to
> guarantee the buffer returned really belongs to the last call of the
> current thread in a multi-threaded environment. I have seen some
> references mentioning malloc is thread safe!. On all platforms and
> implementations ?

I believe that your information regarding this topic is out of date and
that if you grep through the source code of many libraries included with
linux and other operating systems you will find that they do not worry
about using malloc and free. This includes libraries that have been
widely ported such as glib.

> 
> Even for libc functions that allocate memory from inside are
> alternated with functions prefixed with _r and take pointer 
> from the user. Examples: strerror_r, readdir_r.
> 
> Now that we are going to hide the marshall function from user, we are
> OK for now. But really curious to find a good solution for this
> problem.
> 
> --
> Anand Babu
> CaliforniaDigital.com
> Office# +1-510-687-7045
> Cell# +1-510-396-0717
> Home# +1-510-894-0586
> 
> Free as in Freedom <www.gnu.org>
-- 
Ben Woodard <address@hidden>
Red Hat Inc.