[Vm-dev] Unix heartbeat thread vs itimer

Ben Coman btc at openinworld.com
Wed Mar 29 06:45:33 UTC 2017

On Wed, Mar 29, 2017 at 11:03 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 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
>> 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 have 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.

No problem.  Not that I'm an expert.  I didn't know anything about
this last week.  I'm just good at leveraging google search to learn
things I don't know.  My speculations are often a way of trying to
check what I've learnt within our domain.

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

Cool. I just ask the questions that cross my mind to see if the
knowledge is out there to tap.

cheers -ben

More information about the Vm-dev mailing list