Mail Archives: cygwin/1998/04/20/04:05:02
Say,
Whats the deal with all those: _<somefunc>_r procedures in the run-time
that are supposed to protect the "reent" structure and make cygwinb19.dll
thread-safe ???
I found this in the archives:
BEGIN ARCHIVE
=============
Reentrancy
Reentrancy is a characteristic of library functions allowing multiple
processes to use the same address space with assurance that the values
stored in those spaces will remain constant between calls.
Cygnus Solutions implements the library functions to ensure that, whenever
possible, these library functions are reentrant.
However, there are some functions that can not be trivially made reentrant.
Hooks have been provided to allow you to use these functions in a fully
reentrant fashion. These hooks use the structure, _reent, defined in
reent.h.
All functions which must manipulate global information are available in two
versions.
The first version has the usual name, using a single global instance of the
reentrancy structure. The second has a different name, normally formed by
prepending _ and appending _r and taking a pointer to the particular
reentrancy structure to use.
For example, the function, fopen, takes two arguments, file and mode, and
uses the global reentrancy structure. The function, _fopen_r, takes the
argument, struct_reent, which is a pointer to an instance of the reentrancy
structure, file and mode.
Each function which uses the global reentrancy structure uses the global
variable, _impure_ptr, which points to a reentrancy structure.
This means that you have two ways to achieve reentrancy. Both require that
each thread of execution control initialize a unique global variable of
type, struct _reent.
Use the reentrant versions of the library functions, after initializing a
global reentrancy structure for each process. Use the pointer to this
structure as the extra argument for all library functions. Ensure that each
thread of execution control has a pointer to its own unique reentrancy
structure in the global variable, _impure_ ptr, and call the standard
library subroutines.
The following functions are provided in both reentrant and non-reentrant
versions.
Equivalent for errno variable:
_errno_r
------------------------------------------------------------------------
Locale functions:
_localeconv_r
_setlocale_r
------------------------------------------------------------------------
Equivalents for stdio variables:
_stdin_r
_stdout_r
_stderr_r
------------------------------------------------------------------------
stdio functions:
_fdopen_r
_mkstemp_r
_remove_r
_fopen_r
_mktemp_r
_rename_r
_getchar_r
_perror_r
_tempnam_r
_gets_r
_putchar_r
_tmpnam_r
_iprintf_r _puts_r _tmpfile_r
------------------------------------------------------------------------
signal functions:
_raise_r _signal_r
------------------------------------------------------------------------
stdlib functions:
_dtoa_r
_realloc_r
_strtoul_r
_free_r
_srand_r
_system_r
_malloc_r
_strtod_r
_rand_r _strtol_r
------------------------------------------------------------------------
String function:
_strtok_r
------------------------------------------------------------------------
System functions:
_close_r
_lseek_r
_stat_r
_fork_r
_open_r
_unlink_r
_fstat_r
_read_r
_wait_r
_link_r _sbrk_r _write_r
------------------------------------------------------------------------
Time function:
_asctime_r
===========
END ARCHIVE
This entry, in particular, both excites & mystifies me:
<
This means that you have two ways to achieve reentrancy. Both require that
each thread of execution control initialize a unique global variable of
type, struct _reent.
Use the reentrant versions of the library functions, after initializing a
global reentrancy structure for each process. Use the pointer to this
structure as the extra argument for all library functions. Ensure that each
thread of execution control has a pointer to its own unique reentrancy
structure in the global variable, _impure_ ptr, and call the standard
library subroutines.
>
1. I'm not sure how to initialize a reentrancy structure.
2. I'm guessing what is meant is thread and NOT process.
3. What is the 2nd way of achieving reentrancy ???
Are there any examples of this stuff in use anywhere ???
I'm very, very interested in making this work. I do already have some
gnu-win32 threads bouncing around, but I crash on occasion I think
because of reentering system and/of crt calls.
Thanks,
da bisk
----------
> From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
> To: Gilbert W. Pilz Jr <gwpilz AT pobox DOT com>; gnu-win32 AT cygnus DOT com
> Subject: Re: B19: gdb on NT - cannot hit breakpoints on other threads
> Date: Sunday, April 19, 1998 9:00 AM
>
> The cygwinb19.dll is not Thread Safe. If you wish to use thread you
> need to go get the Mingw32 gcc compiler which uses the native
> CRTDLL.DLL which is thread safe. You can find the Mingw32 gcc
> compiler via Colin Peters' page. URL is listed below.
>
> ---"Gilbert W. Pilz Jr" <gwpilz AT pobox DOT com> wrote:
> >
> > Has anyone else seen this problem ?
> >
> > I'm trying to debug a simple program that creates multiple threads
> using
> > CreateThread(). I find that I can set breakpoints on the starting
> routines
> > of the sub-threads, but that when I hit them I get a SIGTRAP instead
> of
> > normal breakpoint behavior. Attempting to continue after the SIGTRAP
> always
> > results in a segmentation violation.
> >
> > Is this a problem with gdb or something I'm doing wrong ?
> >
> >
> >
> >
> > Gilbert W. Pilz Jr.
> > Systems Software Consultant
> > gwpilz AT pobox DOT com
> > www.scruz.net/~gwpilz/
>
> - \\||//
> ---o0O0--Earnie--0O0o----
> --earnie_boyd AT yahoo DOT com--
> ------ooo0O--O0ooo-------
>
snip ...
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -