This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


"Jacob Chr. Poulsen" wrote:
> 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.

To play devils advocate here, do we really think the POSIX signal
handling is such hot stuff?  In the high-res-timers kernel patch I allow
the timer_create call to (optionally) assign ownership of the timer to
any thread in the threadgroup.  The owner of the timer gets the signals
and takes the timer away when he exits, otherwise, any thread in the
threadgroup can do any thing with the timer (set, clear, delete, etc.). 
Folks I have talked to think this is a much saner way of handling
signals.  Of course, this is why I am interested in the CLONE_THREAD
> --
> mvh. Jacob Chr Poulsen
> --- 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.

Real time sched:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]