[Vm-dev] Unix heartbeat thread vs itimer

[Guillermo Polito]

Hi,

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

Yes, I know. I actually arrived here because I was having issues when using
OSSubProcess. The itimer interrupts external commands executed through the
fork/exec. But even worse, fork calls the clone system call, which does not
fail: it restarts! And it gets interrupted again. And this just freezes the
process. :/


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

Yeap, I know it is a big problem. But the thing is that having two
different compiled VMs obligates on one hand to modify all download
scripts, duplicating options, or even it makes me think when I download a
VM if I'm downloading the right one or not...

I'd prefer to have a linux VM with a decent default (let's say the itimer
one to not bother beginners), but the possibility to say:

./vm --threaded-heartbeat myImage.image

for people who know what they are doing :)


>
> 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.
>
> An alternative might be to lower the priority of the main thread.  Then
> the file installation would be unnecessary.
>
> 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.
>

I'll play a bit to see if I can have a version using a flag in a separate
branch.

Guille


>
> >
> > Guille
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170110/780f4611/attachment.html>