[Vm-dev] Unix heartbeat thread vs itimer
Guillermo Polito
guillermopolito at gmail.com
Tue Jan 10 15:21:25 UTC 2017
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>
More information about the Vm-dev
mailing list