In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] wrote:
So far I read this as saying the sched_XXX functions operate on
processes, whereas the pthread_{set|get}schedparam functions operate
on threads.
Me too.
(4) When a running thread calls the sched_setparam()
[EMAIL PROTECTED] wrote:
In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] wrote:
For SCHED_FIFO and SCHED_RR, we don't have a problem because both
the threads library and kernel now agree that the range is 0..31.
SCHED_OTHER is a problem because the threads library
On Sun, Oct 15, 2000 at 00:20 -0400, Daniel Eischen wrote:
On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
(6) If a thread whose policy or priority has been modified is
a running thread or is runnable, runnable thread [sic] it then
becomes the tail of the thread list
In article [EMAIL PROTECTED],
Daniel Eischen [EMAIL PROTECTED] wrote:
I've just committed some changes to the threads library
and would appreciate feedback from anyone running threaded
applications. They include fixes that -stable could really
use.
This commit also implements zero
In article [EMAIL PROTECTED],
Daniel Eischen [EMAIL PROTECTED] wrote:
On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Daniel Eischen [EMAIL PROTECTED] wrote:
The range of valid priorities has also changed, perhaps
requiring a library version bump. The
I've just committed some changes to the threads library
and would appreciate feedback from anyone running threaded
applications. They include fixes that -stable could really
use.
This commit also implements zero system call thread context
switching in the threads library. Switching between