2004-06-11 Antony King <antony.king@st.com>

* libc/include/sys/_types.h: Include <sys/lock.h> and change
        _flock_t to be of type _LOCK_RECURSIVE_T.
        * libc/include/sys/reent.h: (_REENT_INIT): Reformat.
        (_REENT_INIT_PTR): Ditto.  Use memset where appropriate.
        (_global_impure_ptr): New declaration.
        (_GLOBAL_REENT): Change to be _global_impure_ptr.
        * libc/include/sys/stdio.h: Include <sys/lock.h> and
        <sys/reent.h>.
        (_flockfile)[!_SINGLE_THREAD]: Add code for lock call.
        (_funlockfile)[!SINGLE_THREAD]: Ditto.
        * libc/reent/impure.c: Set _global_impure_ptr to _impure_ptr.
        * libc/stdio/fclose.c: Remove casting of fp lock to
        _LOCK_RECURSIVE_T.
        * libc/stdio/findfp.c: Ditto.
        * libc/stdio/fopen.c: Ditto.
        * libc/stdio/freopen.c: Ditto.
        * libc/stdio/vfprintf.c: Ditto.
        * libc/stdio64/fopen64.c: Ditto.
        * libc/stdlib/envlock.c: Add default stubs that use generic
        locking code.
        * libc/stdlib/mlock.c: Ditto.

        Jeff Johnston  <jjohnstn@redhat.com>
        * libc/sys/linux/sys/_types.h (__flock_mutex_t): New subtype.
        (_flock_t): Change to be a struct containing a single member
        named mutex which is of type __flock_mutex_t.
This commit is contained in:
Jeff Johnston
2004-06-11 20:37:10 +00:00
parent af6b55758b
commit d0bd3e6f56
14 changed files with 183 additions and 56 deletions

View File

@ -9,24 +9,24 @@ INDEX
ANSI_SYNOPSIS
#include "envlock.h"
void __env_lock (struct _reent *<[reent]>);
void __env_unlock (struct _reent *<[reent]>);
void __env_lock (struct _reent *<[reent]>);
void __env_unlock (struct _reent *<[reent]>);
TRAD_SYNOPSIS
void __env_lock(<[reent]>)
struct _reent *<[reent]>;
struct _reent *<[reent]>;
void __env_unlock(<[reent]>)
struct _reent *<[reent]>;
struct _reent *<[reent]>;
DESCRIPTION
The <<setenv>> family of routines call these functions when they need
to modify the environ variable. The version of these routines supplied
in the library does not do anything. If multiple threads of execution
can call <<setenv>>, or if <<setenv>> can be called reentrantly, then
you need to define your own versions of these functions in order to
safely lock the memory pool during a call. If you do not, the memory
pool may become corrupted.
The <<setenv>> family of routines call these functions when they need to
modify the environ variable. The version of these routines supplied in the
library use the lock API defined in sys/lock.h. If multiple threads of
execution can call <<setenv>>, or if <<setenv>> can be called reentrantly,
then you need to define your own versions of these functions in order to
safely lock the memory pool during a call. If you do not, the memory pool
may become corrupted.
A call to <<setenv>> may call <<__env_lock>> recursively; that is,
the sequence of calls may go <<__env_lock>>, <<__env_lock>>,
@ -36,16 +36,26 @@ that it already holds.
*/
#include "envlock.h"
#include <sys/lock.h>
#ifndef __SINGLE_THREAD__
__LOCK_INIT_RECURSIVE(static, __env_lock_object);
#endif
void
__env_lock (ptr)
struct _reent *ptr;
{
#ifndef __SINGLE_THREAD__
__lock_acquire_recursive (__env_lock_object);
#endif
}
void
__env_unlock (ptr)
struct _reent *ptr;
{
#ifndef __SINGLE_THREAD__
__lock_release_recursive (__env_lock_object);
#endif
}

View File

@ -21,13 +21,13 @@ TRAD_SYNOPSIS
struct _reent *<[reent]>;
DESCRIPTION
The <<malloc>> family of routines call these functions when they need
to lock the memory pool. The version of these routines supplied in
the library does not do anything. If multiple threads of execution
can call <<malloc>>, or if <<malloc>> can be called reentrantly, then
you need to define your own versions of these functions in order to
safely lock the memory pool during a call. If you do not, the memory
pool may become corrupted.
The <<malloc>> family of routines call these functions when they need to lock
the memory pool. The version of these routines supplied in the library use
the lock API defined in sys/lock.h. If multiple threads of execution can
call <<malloc>>, or if <<malloc>> can be called reentrantly, then you need to
define your own versions of these functions in order to safely lock the
memory pool during a call. If you do not, the memory pool may become
corrupted.
A call to <<malloc>> may call <<__malloc_lock>> recursively; that is,
the sequence of calls may go <<__malloc_lock>>, <<__malloc_lock>>,
@ -37,16 +37,28 @@ that it already holds.
*/
#include <malloc.h>
#include <sys/lock.h>
#ifndef __SINGLE_THREAD__
__LOCK_INIT_RECURSIVE(static, __malloc_lock_object);
#endif
void
__malloc_lock (ptr)
struct _reent *ptr;
{
#ifndef __SINGLE_THREAD__
__lock_acquire_recursive (__malloc_lock_object);
#endif
}
void
__malloc_unlock (ptr)
struct _reent *ptr;
{
}
#ifndef __SINGLE_THREAD__
__lock_release_recursive (__malloc_lock_object);
#endif
}
#endif