[Vm-dev] linux thread priorities

[Igor Stasenko]

On 4 February 2010 07:46, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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).
>
Wow.. 100ms? Sounds like you can't have more than 10 frames per
second. Weird. Can it be because it waits for vsync?

> 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
>
>



-- 
Best regards,
Igor Stasenko AKA sig.