[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?
Cheers,
- Andreas
More information about the Vm-dev
mailing list