gij/eclipse sets SCHED_RR scheduling policy, hogs machine.

[David Daney]

Andrew Haley wrote:
> David Daney writes:
>  > Andrew Haley wrote:
>  > > David Daney writes:
>  > >  > Andrew Haley wrote:
>  > >  > > For some bizarre reason we're setting SCHED_RR when we do
>  > >  > > java::lang::Thread::setPriority ().  I cannot begin to imagine why
>  > >  > > anyone ever thought this might be a good idea.
>  > >  > > 
>  > >  > 
>  > >  > IIRC the current implementation of Thread.setPriority(int) does not work 
>  > >  > on Linux with SCHED_OTHER.  Perhaps it was an attempt to make it work.
>  > >  > 
>  > >  > We have an ugly local hack that uses setpriority() but it does not work 
>  > >  > with NPTL.
>  > > 
>  > > Well, at least one kernel engineer seems to think that's what should
>  > > be done.  I accept that it might not work, but there's notthing better
>  > > that will, so ...
>  > 
>  > I don't doubt that SCHED_RR is the wrong thing.  But it would be nice if 
>  > we could somehow get Thread.setPriority() to actually change the thread 
>  > priority as documented.
> 
> I don't understand.  Are you saying that there is a way to change the
> thread priority?  If so, do you know what it is?
> 

I am not a pthreads expert, but my reading is that unless you choose a 
real time scheduler (i.e. SCHED_RR) there is no portable way to set 
thread priority.

For the old linux-threads (not NPTL) if you get the process id (pid) 
that corresponds to the thread, you can then treat the thread as if it 
were a stand alone process and call setpriority() on its pid.  I have 
never tried this technique with NPTL.  So I know how to hack it for 
older systems that use the 2.4.x kernels, but I have no general solution.

David Daney