This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: B19: threads


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@yahoo.com>
> To: Gilbert W. Pilz Jr <gwpilz@pobox.com>; gnu-win32@cygnus.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@pobox.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@pobox.com
> > www.scruz.net/~gwpilz/
> 
> -        \\||//
> ---o0O0--Earnie--0O0o----
> --earnie_boyd@yahoo.com--
> ------ooo0O--O0ooo-------
> 

snip ...
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]