<br><br><div class="gmail_quote">On Tue, Jan 11, 2011 at 12:26 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
2011/1/11 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div><div></div><div class="h5">><br>
><br>
><br>
> 2011/1/11 Levente Uzonyi <<a href="mailto:leves@elte.hu">leves@elte.hu</a>><br>
>><br>
>><br>
>> On Tue, 11 Jan 2011, Eliot Miranda wrote:<br>
>><br>
>> (Pine can't quote your mail, sorry.)<br>
>><br>
>> "The problem with linux is that the pthreads implementation doesn't allow a normal user-level process to create high-priroity threads so that as<br>
>> soon as the Vm starts to spin doing some computation the heartbeat thread is shut-out and if the spinning computation only interrupted when a delay<br>
>> expires it'll never get interrupted because it is blocking the very thread that would signal the delay. So until linux's pthreads implementation<br>
>> supports multiple priorities we're stuck with hacks like the interval timer based itimer in the linux Cog VMs."<br>
>><br>
>> What about keeping the priority of the heartbeat thread at user-level and decreasing the other VM threads' priority slighly?<br>
><br>
> Linux doesn't allow more than /one/ thread priority for threads in a user-level process. So one /can't/ have multiple priorities. All threads run at the same priority. This is a horrible bug in the linux pthreads implementation but there it is.<br>
> best<br>
> Eliot<br>
<br>
</div></div>Superficial googling "setting linux pthread priority" gives me this<br>
thread (java)<br>
<a href="http://kerneltrap.org/node/6080" target="_blank">http://kerneltrap.org/node/6080</a><br>
<br>
It seems that there are different scheduling policies in linux 2.6<br>
kernel, realTime, and non real time (traditional unix time sharing).<br>
It seems that only real time threads can have their priority set.<br>
<br>
man sched_setscheduler<br>
<br>
After man 7 pthreads, it appears that the scheduling policy would be<br>
different for each thread.<br>
<br>
However, the functionalities of interest are provided by the NPTL<br>
(Native POSIX Threads Library).<br>
The older LinuxThreads implementation might not implement POSIX.1<br>
complying threads.<br>
<br>
So, some linux might work, for example, in my fresh mandriva 2010.2<br>
x86-32, I test<br>
$ getconf GNU_LIBPTHREAD_VERSION<br>
NPTL 2.11.1<br>
<br>
To be confirmed...<br></blockquote><div><br></div><div>You don't have to confirm this. We have confirmed this at length over the past year at Teleplace. realtime scheduling is /not allowed/ in non-super-user processes. So unless the Squeak VM is to be installed setuid and run as root it, like all other non-setuid programs on linux, must make do with a /single/ thread priority.</div>
<div><br></div><div>I have a _few_ test programs that you're welcome to try out if you really don't believe me :)</div><div><br></div><div>best</div><div>Eliot </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Nicolas<br>
<br>
>><br>
>> Levente<br>
><br>
><br>
><br>
</blockquote></div><br>