[Vm-dev] Unix heartbeat thread vs itimer

Ben Coman btc at openinworld.com
Tue Mar 28 17:35:54 UTC 2017

On Tue, Mar 28, 2017 at 11:05 PM, Ben Coman <btc at openinworld.com> wrote:
> 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?

bah, sorry, accidental bump sent too early. To continue..

POSIX timer_create() & timer_settime() might be worth considering,
which can specify a different signal than SIGALARM,
and also can apparently send the signal to a specific thread with with

Now when some places say there can only be one signal handler per
signal per process, but IIUC modern Linux there is no distinction
between process or thread, so its one signal handler per signal per

Or perhaps you just need a particular callback function called when
the timer expires, per Patryk's answer...
Although creating a new thread each time may be too much overhead.

btw, did the change in Linux 2.6.12 from setitimer signalling
individual threads to signalling only the main thread have any
noticeable effect on the operation of the VM and external code like
OSProcess and libraries? per answer by osgx...

cheers -ben

ahh, just saw this from Holger...

> AFAICT the main issue is that it can not be shared/multiplexed. E.g. if both ALSA and the VM install an event handler for the signal it is not clear who will win. And they will probably cancel each others work.

So I guess that means ALSA is using SIGALRM?
Since that is what setitmer is hardcoded to send.  I see a few mentions here...

cheers -ben

More information about the Vm-dev mailing list