Re: signaling threads by pid on linux

At 15:20 -0500 11/3/03, Al Tobey wrote:
>Not only is using pids for threads in linux not portable to other
>unixes, it is likely not portable to newer linux kernels.  NPTL (Native
>POSIX Threading Layer) makes using pids in place of tids less
>straightforward.   This will likely be the default in all Linux
>installations before too long, and has been in Redhat since 8.0.  I
>believe Debian unstable is using it, and all of the Redhat derivatives
>like Mandrake are, of course, using it.  I'm not entirely sure about
>UnitedLinux, though I think it does use NPTL.  Slackware 9.X does not.

Hmmm...  I just tried Thread::Signal on a 2.4.20-8 kernel, and indeed 
Thread::Signal doesn't get through its test there (even though perl 
-V shows that -DTHREADS_HAVE_PIDS is specified as a compile-time 
option).

It seems that getpid (in C) is returning the pid of the main thread...

I'll bring out a new version of Thread::Signal with a more explicit 
warning.  Too bad, it was nice while it lasted.


>So, threads still have pids under 2.6 and NPTL, but they're not shown by
>default because they're not really processes - they're threads.   You
>can still get the same information about a thread you can a process via
>/proc/<pid number>/tasks/<thread pid> but who knows how they'll change
>that interface next time.
>
>I may be crying wolf, but I thought I'd point this out to save people
>trouble down the road.

Defiitely not crying wolf there...

In the 2.4.20-8 kernel, I don't see /proc/<pid>/tasks...  ;-(

I'd appreciate if anybody would have information to be able to 
support this on later versions of Linux...


Liz