[Vm-dev] Unix heartbeat thread vs itimer

[Fabio Niephaus]

On Fri, Jan 6, 2017 at 6:33 PM 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.
>
> 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
heartbeat.


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

Fabio


>
> 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...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170106/5064c016/attachment-0001.html>