public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Ingo Molnar <mingo@elte.hu>, Luca Barbieri <ldb@ldb.ods.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] threading fix, tid-2.5.47-A3
Date: Sun, 17 Nov 2002 19:58:54 -0800	[thread overview]
Message-ID: <3DD8657E.7020203@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0211171938250.8451-100000@home.transmeta.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:

> So when the child eventually creates a new thread, it needs to know to 
> ignore the other thread slots, even though they _look_ valid. They were 
> valid in the parent, they aren't valid in the child.
> 
> No?

They don't have to be as such.  It's a simple list operation (move all
active threads except the active one on the free list).  That's it.  No
more work especially no resetting of the TID fields.


> I follow your argument, and I don't dislike it per se. I just think that 
> you end up having to do other setup for pthreads-after-fork _anyway_, no?

I don't walk the thread descriptors.  I don't write into them.  I move
entire double-linked lists with a dozen or so instructions.  Regardless
of how many threads were active in the parent.


> Basically, I don't see the patch and bits making sense. I see it
> potentially _working_. But that's a different issue - and "working" to me
> is sometimes a much less potent argument than "makes sense".

With the flag and/or two settid pointers available the thread descriptor
for the one thread in the new process is correct and complete from the
first instruction on.  The address of the thread descriptor is the same
in parent and child and the only field which needs changing is the tid.
 I don't know what else to say.  For correct operation the thread
descriptor must be complete and correct and if the kernel doesn't help
setting the descriptor up correctly there always will be a time period
when it is not complete and effectively points to the parent thread in
the old process.  If the clone() flag would not be available I would
probably ignore the problem for now but when it becomes a problem the
only way for user-level code to handle the problem is to disable signals
around fork calls in the parent and then re-enable them after fork() and
after setting up the descriptor in the new process.  And this still
wouldn't help with debuggers etc.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE92GV+2ijCOnn/RHQRAiWpAJ9xxRkqVFFXyMcGwy8Y6udvtpqrvgCfRqm4
msw9MdH4MZ/+57JS9+OKlJQ=
=MWxi
-----END PGP SIGNATURE-----


  reply	other threads:[~2002-11-18  3:51 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3DD7E3E7.6040403@redhat.com>
2002-11-17 18:54 ` [patch] threading fix, tid-2.5.47-A3 Linus Torvalds
2002-11-17 20:18   ` Ingo Molnar
2002-11-17 20:37   ` Ingo Molnar
2002-11-17 19:54     ` Luca Barbieri
2002-11-17 21:17       ` Ingo Molnar
2002-11-17 20:16         ` Luca Barbieri
2002-11-17 21:45           ` Ingo Molnar
2002-11-17 20:35         ` Ulrich Drepper
2002-11-17 20:44           ` Jamie Lokier
2002-11-17 20:49           ` Luca Barbieri
2002-11-17 22:08     ` Ingo Molnar
2002-11-17 23:00     ` Linus Torvalds
2002-11-17 23:23       ` Ulrich Drepper
2002-11-18  1:33         ` Linus Torvalds
2002-11-18  3:33           ` Ulrich Drepper
2002-11-18  3:43             ` Linus Torvalds
2002-11-18  3:58               ` Ulrich Drepper [this message]
2002-11-18  4:11                 ` Linus Torvalds
2002-11-18  4:31                   ` Ulrich Drepper
2002-11-18  6:46                   ` Ulrich Drepper
2002-11-18 16:00                     ` Linus Torvalds
2002-11-18  8:07                   ` Luca Barbieri
2002-11-18  8:21                     ` Ulrich Drepper
2002-11-18  8:27                       ` Luca Barbieri
2002-11-18  9:30                   ` [patch] threading enhancements, tid-2.5.47-C0 Ingo Molnar
2002-11-18  8:29                     ` Luca Barbieri
2002-11-18 12:12                       ` Ingo Molnar
2002-11-18 12:11                         ` Luca Barbieri
2002-11-20  1:40                         ` Ulrich Drepper
2002-11-20  1:59                           ` Linus Torvalds
2002-11-20  3:37                           ` Jamie Lokier
2002-11-20  4:04                             ` Ulrich Drepper
2002-11-20 21:55                               ` Jamie Lokier
2002-11-20 22:11                                 ` Ulrich Drepper
2002-11-20 23:26                                   ` Jamie Lokier
2002-11-20 23:28                                     ` Ulrich Drepper
2002-11-21  0:18                                       ` Jamie Lokier
2002-11-21  9:13                                         ` Ingo Molnar
2002-11-21 12:07                                           ` Jamie Lokier
2002-11-21  0:37                                   ` Jamie Lokier
2002-11-20  8:50                           ` Ingo Molnar
2002-11-20  9:51                             ` [patch] threading enhancements, tid-2.5.48-A1 Ingo Molnar
2002-11-20  8:41                               ` Ulrich Drepper
2002-11-20 20:20                               ` Luca Barbieri
2002-11-21 18:03                                 ` [patch] threading enhancements, tid-2.5.48-C0 Ingo Molnar
2002-11-21 19:30                                   ` Luca Barbieri
2002-11-18  8:30                 ` [patch] threading fix, tid-2.5.47-A3 Luca Barbieri
2002-11-18 12:21                   ` Ingo Molnar
2002-11-18 12:50                     ` Luca Barbieri
2002-11-18 12:26                   ` Ingo Molnar
2002-11-18 13:20                     ` Alan Cox
2002-11-18 13:03                       ` Luca Barbieri
2002-11-18 16:24                       ` Linus Torvalds
2002-11-18 16:42                       ` Ingo Molnar
2002-11-18  1:46       ` Jamie Lokier
2002-11-18  3:40         ` Ulrich Drepper
2002-11-18 22:22           ` Jamie Lokier
2002-11-17 23:37     ` Ulrich Drepper
2002-11-17 12:40 Ingo Molnar
2002-11-17 11:57 ` Luca Barbieri
2002-11-17 13:36   ` Ingo Molnar
2002-11-17 13:49   ` Ingo Molnar
2002-11-17 13:29     ` Luca Barbieri
2002-11-17 17:28 ` Linus Torvalds
2002-11-17 19:03   ` Ulrich Drepper
2002-11-17 19:19   ` Ingo Molnar
2002-11-17 19:31   ` Ingo Molnar
2002-11-17 18:27     ` Linus Torvalds
2002-11-17 20:13       ` Ingo Molnar
2002-11-17 20:01   ` Jamie Lokier

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=3DD8657E.7020203@redhat.com \
    --to=drepper@redhat.com \
    --cc=ldb@ldb.ods.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@transmeta.com \
    /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