CLONE_THREAD

[Jacob Chr. Poulsen]

On Wed, Feb 20, 2002 at 12:06:45AM -0800, george anzinger wrote:
> Daniel Jacobowitz wrote:

> > On Tue, Feb 19, 2002 at 04:20:08PM -0800, george anzinger wrote:
> > It does quite a bit.  For instance, getpid() in the threads will no
> > longer return a unique value per thread, but the thread group ID.
>
> Presumably there is a getthreadid() or some such.  Lets see, LynxOS
> combines the process pid and the threadid in the same word, won't work
> here, but...

looked into the source of the ngpth and found that thay have the folowing.

inline intern pid_t k_gettid(void) {
        return syscall(__NR_gettid);
}

checked my linux 2.4.17 headers and found __NR_gettid as defined in the normal
kernel headers. eq this don't depends on ngpth's kernel patch.

> > On the other hand, I'd like to see LinuxThreads use CLONE_THREAD also.
> > Ulrich, I know that it doesn't begin to cover what LinuxThreads needs
> > from the kernel, but in my conversations with David Howells about the
> > process ornament debugging interface we've agreed that it would be a
> > great deal easier to deal with threaded processes if they belonged to a
> > thread group.

If any start the work on making linuxThreads more posix/programmer/admin friendly
i will gladly, joind with testing / building testcases and code.

I joind this list one week ago with the porpes to follow the glibc development,
start lokking into making linuxThreads more nice :)

my larges problems at the moment is the multible pid from a admin point of view,
and the "wrong" signal routing.

-- 
mvh. Jacob Chr Poulsen
  ja7@dbc.dk 
--- Det Er ingen skam at være ordblid, med holdkeft hvor er det besverligt.
--- it's no chame for a word-bliend not beeing abel to spell duslexica.