Why is __sglue initialized in _cygtls::init_thread()?

Sebastian Huber <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
Hello,

I have a question to _cygtls::init_thread():

void
_cygtls::init_thread (void *x, DWORD (*func) (void *, void *))
{
   if (x)
     {
       memset (this, 0, sizeof (*this));
       _REENT_INIT_PTR (&local_clib);
       stackptr = stack;
       altstack.ss_flags = SS_DISABLE;
       if (_GLOBAL_REENT)
	{
	  local_clib._stdin = _GLOBAL_REENT->_stdin;
	  local_clib._stdout = _GLOBAL_REENT->_stdout;
	  local_clib._stderr = _GLOBAL_REENT->_stderr;
	  if (_GLOBAL_REENT->__cleanup)
	    local_clib.__cleanup = _cygtls::cleanup_early;
	  local_clib.__sglue._niobs = 3;
	  local_clib.__sglue._iobs = &_GLOBAL_REENT->__sf[0];
	}
     }

Why is __sglue initialized here? It seems to be unused in general for 
local_clib.__sglue:

1. The __sglue::next member was still NULL, so even if someone calls 
_reclaim_reent(), cleanup_glue() would not get called.

2. FILE objects are added to the __sglue list only by __sfp().  This 
function only uses the __sglue member of _GLOBAL_REENT.

It could be used by _fcloseall_r() through _fwalk_reent() which seems to 
be unused by Cygwin.

It could be used by __fp_lock_all() and __fp_unlock_all() through 
_fwalk() which is used only by Cygwin in the pthread::atfork*() functions.

It could be used by _cleanup_r() through _fwalk_reent().

In the above three cases the file walk would operate on the three FILE 
objects in _GLOBAL_REENT->__sf. I would like to change the __sglue 
handling, so it would be great if someone could explain the Cygwin use 
case for the __sglue initialization in _cygtls::init_thread().

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: [email protected]
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.