From: mlx AT san DOT rr DOT com (Steve Biskis) Subject: Re: B19: threads 20 Apr 1998 04:05:02 -0700 Message-ID: <199804200421.VAA00673.cygnus.gnu-win32@proxyb1.san.rr.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: Say, Whats the deal with all those: __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 > To: Gilbert W. Pilz Jr ; 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" 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".