All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.