public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Dominik Straßer" <einmal_rupert@gmx.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Russell Leighton <russ@elegant-software.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Using getpid() often, another way? [was Re: clone() <-> getpid() bug in 2.6?]
Date: Sat, 12 Jun 2004 11:15:42 +0200	[thread overview]
Message-ID: <40CAC9BE.6050400@gmx.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0406061013250.7010@ppc970.osdl.org>

Linus Torvalds wrote:

>On Sun, 6 Jun 2004, Russell Leighton wrote:
>  
>
>>Linus said he could not imagine a program using getpid() more than a 
>>handful of times...
>>    
>>
>
>No, I said that I could not imagine using it more than a handful of times 
>_except_ for the cases of:
>
> - thread identification without a native thread area
> - benchmarking.
>
>(and in both of these cases it is _wrong_ to cache the pid value)
>
>  
>
>>well, (I am ashamed to admit it) I found this getpid() bug with just 
>>such a program.
>>
>>Could someone can suggest an alternative to using getpid() for me? 
>>Here's the problem...
>>
>>I have a library that creates 2 threads using clone().
>>    
>>
>
>Your problem falls under the thread ID thing. It's fine and understandable 
>to use getpid() for that, although you could probably do it faster if you 
>are willing to use the support that modern kernels give you and that glibc 
>uses: the "TLS" aka Thread Local Storage support.
>
>Thread-local storage involved having a user-mode register that points some 
>way to a special part of the address space. On x86, where the general 
>register set is very limited and stealing a general reg would thus be bad, 
>it uses a segment and loads the TLS pointer into a segment register 
>(segment registers are registers too - and since nobody sane uses them for 
>anything else these days, both %gs and %fs are freely usable).
>
>  
>
>> Would gettid() be any better?
>>    
>>
>
>You'd avoid this particular glibc bug with gettid.
>  
>
I am facing the following problem:
I want to sum up the time spent in the main thread + all threads that 
ever existed.
getrusage dosn't work (and didn't do so in pre-NPTL-times) as the time 
spent in threads is not taken into account.
To work around this problem I created a map pid->time used which used 
getpid in the pre-NPTL-time and looked up the time in /proc/<pid>. As 
this doesn't work with NPTL, changed it to use the gettid syscall as I 
didn't find a saner way.

Regards

Dominik

  reply	other threads:[~2004-06-12  9:15 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-05 15:28 clone() <-> getpid() bug in 2.6? Russell Leighton
2004-06-05 20:45 ` Linus Torvalds
2004-06-05 20:55   ` Arjan van de Ven
2004-06-05 21:13     ` Linus Torvalds
2004-06-05 21:48       ` Robert Love
2004-06-05 22:44         ` Linus Torvalds
2004-06-05 21:53     ` Chris Wedgwood
2004-06-05 22:47       ` Robert Love
2004-06-05 22:57         ` David S. Miller
2004-06-05 23:01         ` Linus Torvalds
2004-06-05 23:07         ` Davide Libenzi
2004-06-05 23:18           ` Linus Torvalds
2004-06-05 23:26             ` Davide Libenzi
2004-06-06  5:08             ` Kalin KOZHUHAROV
2004-06-06  5:13               ` Chris Wedgwood
2004-06-06  5:34                 ` Kalin KOZHUHAROV
2004-06-06  6:07               ` Linus Torvalds
2004-06-06  6:43                 ` Kalin KOZHUHAROV
2004-06-06  7:57                 ` Erik Andersen
2004-06-06 16:57                   ` Linus Torvalds
2004-06-06 18:53                     ` Simon Kirby
2004-06-06 19:00                       ` Linus Torvalds
2004-06-06  9:52                 ` Bernd Eckenfels
2004-06-06 13:07                   ` Paul Rolland
2004-06-06 17:20                     ` Patrick J. LoPresti
2004-06-06 17:31                       ` Paul Rolland
2004-06-06 17:43                       ` Davide Libenzi
2004-06-06 18:17                       ` Rik van Riel
2004-06-06 18:37                         ` Patrick J. LoPresti
2004-06-06 16:33                 ` chris
     [not found]                 ` <200406062022.54320.vda@port.imtp.ilyichevsk.odessa.ua>
2004-06-06 17:55                   ` Linus Torvalds
2004-06-07 18:20                 ` Bruce Guenter
2004-06-08 11:06                   ` Kalin KOZHUHAROV
2004-06-05 23:19           ` Robert Love
2004-06-06 14:29   ` Russell Leighton
2004-06-06 15:38     ` Using getpid() often, another way? [was Re: clone() <-> getpid() bug in 2.6?] Russell Leighton
2004-06-06 15:44       ` Robert Love
2004-06-07  0:20         ` Russell Leighton
2004-06-06 15:58       ` Arjan van de Ven
2004-06-06 23:49         ` Russell Leighton
2004-06-07 12:13           ` Arjan van de Ven
2004-06-07 13:48             ` Sean Neakums
2004-06-07 14:00               ` Christoph Hellwig
2004-06-07 14:10                 ` Sean Neakums
2004-06-07 18:42                 ` David Mosberger
2004-06-07 23:02                   ` Russell Leighton
2004-06-07 23:27                     ` David Mosberger
2004-06-08  6:01                     ` Arjan van de Ven
2004-06-08  9:48                       ` Eric W. Biederman
2004-06-07  0:09         ` Russell Leighton
2004-06-07 12:20           ` Arjan van de Ven
2004-06-06 17:19       ` Linus Torvalds
2004-06-12  9:15         ` Dominik Straßer [this message]
2004-06-12 13:47           ` Linus Torvalds

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=40CAC9BE.6050400@gmx.de \
    --to=einmal_rupert@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=russ@elegant-software.com \
    --cc=torvalds@osdl.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