This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: CLONE_THREAD
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.