[Vm-dev] Unix heartbeat thread vs itimer

[Ben Coman]

On Sat, Jan 7, 2017 at 1:33 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Guille,
>
>> On Jan 6, 2017, at 6:44 AM, Guillermo Polito <guillermopolito at gmail.com> wrote:
>>
>> Hi,
>>
>> I was checking the code in sqUnixHeartbeat.c to see how the heartbeat thread/itimer worked. It somehow bothers me that there are different compiled artifacts, one per option.
>>
>> What do you think about having a VM that manages that as an argument provided when we launch the VM? This would add some flexibility that we don't have right now because we make the decision at compile time.
>
> I think it's a fine idea but it isn't really the issue.  The issue is that the itimer mechanism is problematic, especially for foreign code, and is therefore a stop gap.  The itimer interrupts long-running system calls, which means that things like sound libraries break (at Qwaq I had to fix ALSA to get it to work with the itimer heartbeat).  Since Pharo is becoming more reliant on external code it may impact us more going forward.

Just curious, what is the root cause of this itimer conflict?
Is it that a SIGALARM in particular is issued, or just that the
current execution is pre-empted to handle the signal - and is that a
timing issue, or a concurrency problem where some state is
invalidated?

Would it help if to handle the signal in another thread?






I found this of mild interest also. Maybe of use if you want to
hibernate your laptop without closing a running Image ??
(I'm not sure whether that's a problem anyway.)
* Deferrable timers for user space   (https://lwn.net/Articles/588086)