From ccfea73fc58c2319218b39eac23f66d06ab50035 Mon Sep 17 00:00:00 2001 From: Olaf Barthel Date: Tue, 11 Oct 2005 08:28:32 +0000 Subject: [PATCH] - Updated the thread-safe library documentation section. git-svn-id: file:///Users/olsen/Code/migration-svn-zu-git/logical-line-staging/clib2/trunk@15039 87f5fb63-7c3d-0410-a384-fd976d0f7a62 --- documentation/README.html | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/documentation/README.html b/documentation/README.html index 16ae3ed..f27e6f1 100644 --- a/documentation/README.html +++ b/documentation/README.html @@ -64,13 +64,33 @@ preprocesssor symbold defined. Note that 'thread-safe' does not mean 'reentrant'. Multiple callers for certain library functions are permitted, but not for all of them. For example, mkdtemp() is not thread-safe, and neither is rand() or localtime(). But as per POSIX 1003.1c-1995 there are thread-safe -variants of rand() and localtime() called rand_r(), localtime_r(), and others. -The use of the socket I/O functions is still problematic because the -underlying bsdsocket.library API is not supposed to be used by any process -other than the one that opened it. Also yet unsolved is the issue of reading -error codes from the errno variable which currently always contains the -error code left by the last caller.

+variants of rand() and localtime() called rand_r(), localtime_r(), and others.

+

The use of the socket I/O functions is still problematic because the +underlying bsdsocket.library API is not supposed to be used by any process +other than the one that opened it. While one TCP/IP stack (my own "Roadshow") allows you +to share the library base among different processes, if so configured, it is the +exception. No other TCP/IP stack available for the Amiga robustly supports a similar +feature. Any attempt to enable it by default would introduce incompatibilities which +might be difficult to support.

+ +

Also yet unsolved is the issue of reading +error codes from the errno variable which currently always contains the +error code left by the last caller. This is also the case for the global h_errno +variable, which the socket I/O name resolution functions may change.

+ +

A much more serious problem resides with the exit(), abort(), +assert() and raise() functions, and the how SIGINT signal is +processed. In the thread-safe library only the main() function may directly +or indirectly call the exit() function. No child process may do so, since this +would wreck its stack context, crashing it instantly; the main program would be very +likely to crash, too, because exit() will clean up after all memory allocations +and files currently in use. Functions such as abort() and raise() may +call the exit() function indirectly. And the raise() function may +be invoked as part of the Control+C checking. You should make sure that the +signal handling does not affect any child processes. This can be done by replacing the +__check_abort() function or by disabling SIGINT processing altogether, +such as through a signal(SIGINT,SIG_IGN) call.

3. What does it not do?

@@ -299,6 +319,6 @@ can reach me at:

Or via e-mail:

-

olsen@sourcery.han.de

+

olsen@sourcery.han.de