public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: newlib@sourceware.org
Subject: Re: Why is __sglue initialized in _cygtls::init_thread()?
Date: Fri, 1 Apr 2022 15:34:26 +0200	[thread overview]
Message-ID: <Ykb/Yr7Co4SeZO37@calimero.vinschen.de> (raw)
In-Reply-To: <e33a58f7-902c-165e-bbd5-478c9d8e8252@embedded-brains.de>

On Mar 30 10:58, Sebastian Huber wrote:
> 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.

Yes, all threads basically just copy _GLOBAL_REENT stdio.

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

It's used, see cygwin_setmode() in syscalls.cc.

> 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().

The original reason to do this is hidden in history, apparently.
git blame points to an 18 years old patch from Chris Faylor:

commit 5e0f482f2cac33d5ce758e4dc0f665a4e195f4e1
Author: Christopher Faylor <...>
Date:   Mon Jan 26 18:52:02 2004 +0000

    * cygtls.cc (_threadinfo::init_thread): Add more local reent stdio
    initialization.
    * dcrt0.cc (initial_env): Can it really be true that XP doesn't allow attaching
    a debugger during DLL attach?  Add temporary workaround.
    (dll_crt0_0): Ensure that _impure_ptr stdio is initialized before any threads.
    (dll_crt0_1): Move _impure_ptr initialization to dll_crt0_0.
    * exceptions.cc (try_to_debug): Reinstate old method for looping while
    debugging.
    * syscalls.cc (_cygwin_istext_for_stdio): Regularize debugging output.  Remove
    hopefully extraneous check.
    (setmode_helper): Add debugging output for improbable case.  Use "binary"
    rather "raw" for consistency.

Guessing from the commit message, it seems this is just trying to copy
the essential stdio parts for the per-thread _REENT initialization.

> 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().

The use cases are probably just those you outlined above.  When changing
how __sglue works, just keep in mind that _cygtls::init_thread needs to
copy the essential global stdio state into the per-thread _REENT.  Given
that __sglue is never actually used *directly* by Cygwin, any change
within newlib should be transparent to Cygwin.

Corinna


      reply	other threads:[~2022-04-01 13:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30  8:58 Sebastian Huber
2022-04-01 13:34 ` Corinna Vinschen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ykb/Yr7Co4SeZO37@calimero.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).