$$ of thread?
Elizabeth Mattijsen
I realise that it is not portable, but a combination of the process number
and "nice" would give you some kind of prioritising. I just checked that
at least under Linux, if you externally change the nice of a thread, it
_does_ get more (or less) CPU than other threads.
And no, $$ gives you the process number of thread 0, _not_ the thread
you're currently in. ;-)
Of course, I would put this in a module, e.g. Thread::Priority, which would
become a no-op on systems that wouldn't allow this...
Would this make any sense?
Liz
Rafael Garcia-Suarez
> Is it possible to get at the process number of the process handling a thread?
POSIX::getpid should work, am I correct ?
> I realise that it is not portable, but a combination of the process number
> and "nice" would give you some kind of prioritising. I just checked that
> at least under Linux, if you externally change the nice of a thread, it
> _does_ get more (or less) CPU than other threads.
>
> And no, $$ gives you the process number of thread 0, _not_ the thread
> you're currently in. ;-)
$$ is not a magic variable. It's initialized when the perl interpreter
starts or forks.
It's possible to change it to a \0-magic variable so it performs
a getpid() each time it's read. But there's POSIX::getpid() that does
the job.
Tony Cook
> Elizabeth Mattijsen wrote:
> > Is it possible to get at the process number of the process handling a thread?
>
> POSIX::getpid should work, am I correct ?
POSIX::getpid() just returns $$
--
Tony
Rafael Garcia-Suarez
That's right, I should have looked at it instead.
So I guess the consistent way to solve the problem is to
add magic to $$, at least for threaded perls on platforms
where threads have a separate PID. (Is this the case for
other platforms than Linux ?)
--
Rafael Garcia-Suarez
Elizabeth Mattijsen
>So I guess the consistent way to solve the problem is to
>add magic to $$, at least for threaded perls on platforms
>where threads have a separate PID. (Is this the case for
>other platforms than Linux ?)
It's not really a problem, and I'm not asking to have $$ change it's
current behaviour. If you want to kill a Perl threaded application,
killing one $$ value should be enough.
It's just that for this scheduling priority thing, at least under Linux, it
would be nice if there would be _another_ way to get at the pid of the
thread process.
Liz
Rafael Garcia-Suarez
> It's not really a problem, and I'm not asking to have $$ change it's
> current behaviour. If you want to kill a Perl threaded application,
> killing one $$ value should be enough.
>
> It's just that for this scheduling priority thing, at least under Linux,
> it would be nice if there would be _another_ way to get at the pid of
> the thread process.
Sure :
(that's a job for Inline::C)
#!perl
use Inline C => 'int getpidofthread() { return (int)getpid(); }';
print "pid=",getpidofthread(),"\n";
print '$$ =',$$,"\n";
__END__
But if we don't fix it, we should document that $$ returns the PID
of the parent thread under Linux.
Colin Watson
> So I guess the consistent way to solve the problem is to
> add magic to $$, at least for threaded perls on platforms
> where threads have a separate PID.
The first thing a fork()ed interpreter does is reset $$ to the value of
getpid(). Why not do the same in Perl_ithread_run()?
--
Colin Watson [cjwa...@flatline.org.uk]
Elizabeth Mattijsen
>On Fri, Aug 02, 2002 at 09:06:14AM +0200, Rafael Garcia-Suarez wrote:
> > So I guess the consistent way to solve the problem is to
> > add magic to $$, at least for threaded perls on platforms
> > where threads have a separate PID.
>The first thing a fork()ed interpreter does is reset $$ to the value of
>getpid(). Why not do the same in Perl_ithread_run()?
Hmmm... I don't think that would be wise, as Perl, at least currently,
considers all the threads as one whole. A die() in any thread takes the
whole thing down, a kill of $$ will take itself down.
I'd rather see this appear as an accessor method on the "threads" object.
$pid = $thread->pid; # pid of thread of which you have an object
$ownpid = threads->self->pid; # my own local $pid
This would allow for more flexibility, e.g. sending signals to a specific
thread. Don't know how portable this would be though... Maybe the "pid"
concept should be more generalized so that it can be used in kill()
portably. That is, if ->pid gives some dummy value on a non-Linux system,
then kill() should be able to handle it accordingly, i.e. deliver the
signal to that particular thread only.
But I guess this could get hairy pretty quickly...
Liz
Nick Ing-Simmons
>Is it possible to get at the process number of the process handling a thread?
>
>I realise that it is not portable, but a combination of the process number
>and "nice" would give you some kind of prioritising. I just checked that
>at least under Linux, if you externally change the nice of a thread, it
>_does_ get more (or less) CPU than other threads.
Linux is "unsual" in having threads in the process table.
Most threaded Unixes (and Win32) have APIs which used the thread id
to change the priority.
>
>And no, $$ gives you the process number of thread 0, _not_ the thread
>you're currently in. ;-)
>
>Of course, I would put this in a module, e.g. Thread::Priority, which would
>become a no-op on systems that wouldn't allow this...
Most if not all thread systems have a concept of thread priority.
Giving access to that would be good - the snag will be sorting out
the "meaning" of priority.
>
>
>Would this make any sense?
>
>
>Liz
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Nick Ing-Simmons
>Elizabeth Mattijsen wrote:
>> Is it possible to get at the process number of the process handling a thread?
>
>POSIX::getpid should work, am I correct ?
POSIX::getpid had better return the Process IDentifier - i.e. the
same for all threads in the process - or the system's POSIX is broken.
Rafael Garcia-Suarez
>
> POSIX::getpid had better return the Process IDentifier - i.e. the
> same for all threads in the process - or the system's POSIX is broken.
OK. So we do agree on this doc patch :
--- pod/perlvar.pod.orig Thu Jul 18 21:39:53 2002
+++ pod/perlvar.pod Fri Aug 2 11:09:45 2002
@@ -769,6 +769,11 @@ =head2 Predefined Names
consider this variable read-only, although it will be altered
across fork() calls. (Mnemonic: same as shells.)
+Note for Linux users : Linux stores thread ids as process ids, so each
+thread has a different PID. This is I<not> reflected in this variable.
+C<$$> gives you the PID of the parent thread. (The same remark applies
+to C<POSIX::getpid()>.)
+
=item $REAL_USER_ID
=item $UID
End of Patch.
Nick Ing-Simmons
>
>So I guess the consistent way to solve the problem is to
>add magic to $$, at least for threaded perls on platforms
>where threads have a separate PID. (Is this the case for
>other platforms than Linux ?)
As far as I know Linux is unique
Nick Ing-Simmons
>On Fri, Aug 02, 2002 at 09:06:14AM +0200, Rafael Garcia-Suarez wrote:
>> So I guess the consistent way to solve the problem is to
>> add magic to $$, at least for threaded perls on platforms
>> where threads have a separate PID.
>
>The first thing a fork()ed interpreter does is reset $$ to the value of
>getpid(). Why not do the same in Perl_ithread_run()?
Because $$ is process id. If you want the thread id the OS's thread id
is in the thread structure and it would be easy to fish it out
with something in threads.xs
Arthur Bergman
On torsdag, augusti 1, 2002, at 09:27 , Rafael Garcia-Suarez wrote:
>
> POSIX::getpid should work, am I correct ?
>
>> I realise that it is not portable, but a combination of the process
>> number
>> and "nice" would give you some kind of prioritising. I just checked
>> that
>> at least under Linux, if you externally change the nice of a thread, it
>> _does_ get more (or less) CPU than other threads.
>>
>> And no, $$ gives you the process number of thread 0, _not_ the thread
>> you're currently in. ;-)
>
> $$ is not a magic variable. It's initialized when the perl interpreter
> starts or forks.
>
> It's possible to change it to a \0-magic variable so it performs
> a getpid() each time it's read. But there's POSIX::getpid() that does
> the job.
>
Not to mention the fact that $$ should be the process id and
POSIX::getpid should get the process id.
Arthur
Tim Bunce
>
> A die() in any thread takes the whole thing down
Can you demonstrate that?
Tim.
Arthur Bergman
On fredag, augusti 2, 2002, at 09:06 , Rafael Garcia-Suarez wrote:
>
> That's right, I should have looked at it instead.
>
> So I guess the consistent way to solve the problem is to
> add magic to $$, at least for threaded perls on platforms
> where threads have a separate PID. (Is this the case for
> other platforms than Linux ?)
>
> -- Rafael Garcia-Suarez
No that is a very wrong thing to do, $$ is process id, just because
linux does threads by doing a fork with shared memory (both are clone())
things so they seem to be children.
If one feels the urge to do thread priority thingies I can recommend one
to implment posix thread priorities.
Arthur
Arthur Bergman
On fredag, augusti 2, 2002, at 09:43 , Rafael Garcia-Suarez wrote:
>
> But if we don't fix it, we should document that $$ returns the PID
> of the parent thread under Linux.
>
Incorrect, it returns the PID, under linux threads happen to get PIDs.
Arthur
Rafael Garcia-Suarez
>>
>> But if we don't fix it, we should document that $$ returns the PID
>> of the parent thread under Linux.
>>
>
> Incorrect, it returns the PID, under linux threads happen to get PIDs.
Pardon my poor phrasing; I meant, "the value of $$ should be coherent
across all threads, and document that on Linux this behaviour is
different from the OS's getpid() call". Is this what you meant ?
And we have also a problem with getppid() (the perl function)
and POSIX::getppid() (which does the same) : it's always a direct
call to the underlying C getppid(), so its value is subject to change
across different threads on Linux. This is inconsistent with $$
and POSIX::getpid().
Elizabeth Mattijsen
Nope. See my previous reply. I confused exit() with die(). Although
exit() still has issues when a thread other than the main thread, does an
exit().
Liz
Nick Ing-Simmons
>Arthur Bergman wrote:
>>>
>>> But if we don't fix it, we should document that $$ returns the PID
>>> of the parent thread under Linux.
>>>
>>
>> Incorrect, it returns the PID, under linux threads happen to get PIDs.
>
>Pardon my poor phrasing; I meant, "the value of $$ should be coherent
>across all threads, and document that on Linux this behaviour is
>different from the OS's getpid() call". Is this what you meant ?
No it isn't what we meant. I sincerly hope that Linux's getpid() returns
process id in all threads. The "fact" that threads show up in "ps"
and /proc/... is a OS-internals thing, the POSIX API had better behave.
to use process
>
>And we have also a problem with getppid() (the perl function)
>and POSIX::getppid() (which does the same) : it's always a direct
>call to the underlying C getppid(), so its value is subject to change
>across different threads on Linux. This is inconsistent with $$
>and POSIX::getpid().
Rafael Garcia-Suarez
>
> No it isn't what we meant. I sincerly hope that Linux's getpid() returns
> process id in all threads. The "fact" that threads show up in "ps"
> and /proc/... is a OS-internals thing, the POSIX API had better behave.
> to use process
Linux 2.2 is not POSIX-compliant : (and the problem affects getppid too)
$ cat foo.pl
#!/opt/blead/bin/perl
use Inline C => <<'**C**';
int getpidofthread() { return (int)getpid(); }
int getppidofthread() { return (int)getppid(); }
**C**
use threads;
sub printpids {
print "pid=",getpidofthread(),' - $$=',$$,"\n",
"ppid=",getppidofthread()," - perl=",getppid(),"\n",
}
threads->new( \&printpids );
sleep 2;
printpids();
$ ./foo.pl
pid=15776 - $$=15774
ppid=15775 - perl=15775
pid=15774 - $$=15774
ppid=13539 - perl=13539
Nick Ing-Simmons
Interesting. So what is/was 15775 ? i.e. thread's parent isn't the
thing that started it!