[Vm-dev] linux thread priorities

Andreas Raab andreas.raab at gmx.de
Thu Feb 4 05:46:30 UTC 2010

Eliot Miranda wrote:
> I think one interim solution to explore is to run the sound pump from 
> the VM thread in the VM's check for events code.  In the Cog VMs a 1KHz 
> heartbeat updates the wall clock and causes the VM to break out of 
> native code and check for events (ideally the heartbeat is a separate 
> thread).  An mentioned, on linux the heartbeat is a software signal from 
> an interval timer.  The software interrupt serves also to interrupt any 
> system calls (e.g. in relinquishProcessorForMilliseconds).  I can extend 
> the heartbeat to set a flag saying "run the sound pump" which will be 
> checked by the VM when checking for events and it will invoke the sound 
> pump code.  The problem here is that any long-running activities that 
> aren't interruptable by the software interrupt (OpenGL rendering?) will 
> delay the sound pump.  So this is either doomed to failure or might just 
> work depending on those other activities.  Comments?  Try it, waste of time?

We know that SwapBuffers() can take north of 100msecs although we might 
be able to mitigate that a little by proper use of fences. I'd ask Josh 
when he's back if he thinks it's reasonable to up the sound pipe to 
100msecs or more latency (I suspect the answer is no).

The alternative would be to make such calls threaded. Perhaps the sound 
thread is susceptible to using the same wakeup technique as in the 
threaded FFI? I.e., if the software interrupt notices that you're still 
in the same primitive, call the sound pump regardless and join (if 
necessary) upon return from that long running primitive?

   - Andreas

More information about the Vm-dev mailing list