From 8a0efa53e44919bcf5ccb1d3353618a82afdf8bc Mon Sep 17 00:00:00 2001 From: Christopher Faylor Date: Thu, 17 Feb 2000 19:39:52 +0000 Subject: import newlib-2000-02-17 snapshot --- newlib/libc/stdlib/envlock.c | 48 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 newlib/libc/stdlib/envlock.c (limited to 'newlib/libc/stdlib/envlock.c') diff --git a/newlib/libc/stdlib/envlock.c b/newlib/libc/stdlib/envlock.c new file mode 100644 index 000000000..0ef6ec491 --- /dev/null +++ b/newlib/libc/stdlib/envlock.c @@ -0,0 +1,48 @@ +/* +FUNCTION +<<__env_lock>>, <<__env_unlock>>--lock environ variable + +INDEX + __env_lock +INDEX + __env_unlock + +ANSI_SYNOPSIS + #include "envlock.h" + void __env_lock (void *<[reent]>); + void __env_unlock (void *<[reent]>); + +TRAD_SYNOPSIS + void __env_lock(<[reent]>) + char *<[reent]>; + + void __env_unlock(<[reent]>) + char *<[reent]>; + +DESCRIPTION +The <> 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 <>, or if <> 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 <> may call <<__env_lock>> recursively; that is, +the sequence of calls may go <<__env_lock>>, <<__env_lock>>, +<<__env_unlock>>, <<__env_unlock>>. Any implementation of these +routines must be careful to avoid causing a thread to wait for a lock +that it already holds. +*/ + +void +__env_lock (ptr) + struct _reent *ptr; +{ +} + +void +__env_unlock (ptr) + struct _reent *ptr; +{ +} -- cgit v1.2.3