<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 6, 2017 at 6:33 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Guille,<br>
<span class=""><br>
> On Jan 6, 2017, at 6:44 AM, Guillermo Polito <<a href="mailto:guillermopolito@gmail.com">guillermopolito@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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. :/ </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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...</div><div><br></div><div>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:</div><div><br></div><div>./vm --threaded-heartbeat myImage.image</div><div><br></div><div>for people who know what they are doing :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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).<br>
<br>
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.<br>
<br>
An alternative might be to lower the priority of the main thread.  Then the file installation would be unnecessary.<br>
<br>
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.<br>
<span class=""><br>
><br>
> The code in sqUnixHeartbeat.c is not a lot nor very complex, it should not be difficult to do...<br>
><br>
> Also, what would be the drawbacks besides an increase on the vm size?<br>
<br>
</span>I hope I've explained above that I expect the drawbacks will be intermittent failures of external code.<br></blockquote><div><br></div><div>I'll play a bit to see if I can have a version using a flag in a separate branch.</div><div><br></div><div>Guille</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> Guille<br>
</blockquote></div><br></div></div>