From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 198013947408 for ; Fri, 1 Apr 2022 13:34:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 198013947408 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648820070; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=YIZsrguiM+5pN/Wg0C/PCRnkQU1AvBKCPApqrQDFBdI=; b=CJ0MjJ8Y0dDkIGOy+VpXyn1I9Sky05VhxN/3fL6SjoBKrokX6MucHNw6vnSiOpwIfEMWdQ ZL4a8vwEFx135JKgZbeZAi+Q18RIpwnSMuM4gyjCQMDRrk2iCIENromtLIdAPEkj14+yQa OF9BjhqfXZE/AyR99r/Gm21uLbzrb9o= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-619-DA7DOT98OqCtJ-Mruj7Lag-1; Fri, 01 Apr 2022 09:34:29 -0400 X-MC-Unique: DA7DOT98OqCtJ-Mruj7Lag-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 251973822214 for ; Fri, 1 Apr 2022 13:34:29 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.36.112.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B02A240CF8F4 for ; Fri, 1 Apr 2022 13:34:28 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id D0788A80E79; Fri, 1 Apr 2022 15:34:26 +0200 (CEST) Date: Fri, 1 Apr 2022 15:34:26 +0200 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: Why is __sglue initialized in _cygtls::init_thread()? Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vinschen@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2022 13:34:33 -0000 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