[Vm-dev] Unix heartbeat thread vs itimer
lists at fniephaus.com
Fri Jan 6 17:44:16 UTC 2017
On Fri, Jan 6, 2017 at 6:33 PM Eliot Miranda <eliot.miranda at gmail.com>
> Hi Guille,
> > On Jan 6, 2017, at 6:44 AM, Guillermo Polito <guillermopolito at gmail.com>
> > 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.
> The real issue is that linux's requirement that thread priorities be set
> in per-application file in /etc/security/limits.d (IIRC) is a big. Neither
> Windows nor Mac OS X requires such nonsense, and a threaded heartbeat is
> used on those systems without any issue at all. Why linux erected this
> mess in the first place is something I don't understand.
> I had to implement the itimer heartbeat to get Qwaq forums running on
> Linux running pre 2.6 kernels, but had many other problems to solve as a
> result (ALSA, database connects).
> Were it that the vm merely had to detect whether it could use the threaded
> heartbeat then things would be easy. Instead one can only use the thing if
> one has superuser permissions to install a file in /etc, just to use a
> thread of higher priority than the main one.
Thanks for the explanation, Eliot. I had no idea how bad the issues are
with the itimer, but I'm glad you also see the user-facing issue with the
> An alternative might be to lower the priority of the main thread. Then
> the file installation would be unnecessary.
Could you elaborate a little bit more on this idea? How could this impact
the vm? What could be the drawbacks here?
> To summarize, the itimer heartbeat is to be avoided as much as possible.
> It causes hard to debug issues with external code, has to be turned off and
> on around fork. It's a stop gap. Having to install a file in /etc just to
> be able to use a thread is insane (and AFAICT unique to linux). Whatever
> you do in the short term to deal with these problems I'll support, but in
> the long term we simply want a threaded heartbeat without needing to
> install anything.
> > The code in sqUnixHeartbeat.c is not a lot nor very complex, it should
> not be difficult to do...
> > Also, what would be the drawbacks besides an increase on the vm size?
> I hope I've explained above that I expect the drawbacks will be
> intermittent failures of external code.
> > Guille
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev