[Vm-dev] Unix heartbeat thread vs itimer

Eliot Miranda eliot.miranda at gmail.com
Wed Mar 29 03:03:51 UTC 2017


Hi Ben,

> On Mar 28, 2017, at 10:35 AM, Ben Coman <btc at openinworld.com> wrote:
> 
> 
>> 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

I don't know.  I do not ha e the cycles or the inclination to keep up with Linux kernel changes.  Once something works I tend to move on.

I have noticed (but have to test more carefully) that the VM as ammended by David Lewis not to abort if permission to raise thread priority is denied ran on my 6.5 CentOS installation without complaint after I renamed squeak.conf, logged out and logged back in.  I need the check that this continues after a reboot rather than just log out/log in.  But perhaps the thread priority issue is fixed.

Anyway, your interest and expertise is much appreciated.  Feel free to experiment and make changes.  Realize that I'm not "all over this" issue because there are many fish to fry.  So I'm very thankful for your efforts here.  
> 
> 
> 
> 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


More information about the Vm-dev mailing list