[Vm-dev] Unix heartbeat thread vs itimer

[Ben Coman]

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
SIGEV_THREAD_ID
https://linux.die.net/man/2/timer_create
https://lists.gt.net/linux/kernel/1289398

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


Or perhaps you just need a particular callback function called when
the timer expires, per Patryk's answer...
http://stackoverflow.com/questions/5740954/problem-in-timers-and-signal
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...
http://stackoverflow.com/questions/2586926/setitimer-sigalrm-multithread-process-linux-c



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...
http://git.alsa-project.org/?p=alsa-kernel.git&a=search&h=HEAD&st=commit&s=sigalrm

cheers -ben