[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-glibc
Subject:    Re: gdb-4.17.0.11 and linux threads: zombie threads, scheduling
From:       Xavier Leroy <Xavier.Leroy () trusted-logic ! fr>
Date:       1999-05-07 15:28:44
[Download RAW message or body]

> * I'm using a mix of SCHED_FIFO threads and SCHED_OTHER threads. It
> seems that threads created with NULL attributes are given FIFO
> scheduling, despite the man-pages leading me to believe that SCHED_OTHER
> should be default. The second program below illustrates this.

You might want to set the "inheritsched" attribute to PTHREAD_EXPLICIT_SCHED
just to make sure that scheduling parameters are not inherited from
the parent thread.  (Although it might be the default; I can't
remember.)  If the problem is still here, that might be a bug in
LinuxThreads.

> * is it legal according to the POSIX-standard to free the memory where a
> pthread_t for a live thread is stored? Under Linux this seems to be the
> case, but can I know that pthread_t isn't a struct holding critical
> thread data?

Well, there is no pthread_t_destroy() function in the POSIX standard,
so I take this as a strong hint that all pthread implementations
should not store anything that requires finalization in a pthread_t.
Basically, pthread_t is some kind of pointer to the thread data,
not the data itself.

> * Is it possible to somehow trace the kernel scheduler?

I don't know of any way to do this, but you might want to ask on the
linux-kernel list.

All the best,

- Xavier Leroy

[prev in list] [next in list] [prev in thread] [next in thread]