Hi Guille,

> On Jan 6, 2017, at 6:44 AM, Guillermo Polito <guillermopolito@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.

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.

>
> Guille