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.
IMHO, the heartbeat thread vm makes it unnecessarily hard to get started with Squeak/Pharo for beginners. Power-users should know that heartbeat thread vms are faster and how to set them up, but requiring all users to have sudo permissions on their system in order to support a heartbeat thread vm seems wrong. So, +1 for vms that support both. It'd be even better if a vm automatically picks a heatbeat thread if the system supports it, so all you have to do is raising the rtprio limit and reopen the vm. In addition, we aren't able to run heartbeat thread vms on TravisCI's Docker-based infrastructure, in fact, it's quite complicated to run these vms on Docker anyway (poweruser expertise needed). However, we can currently run them on Travis' sudo-enabled containers, but those builds are much slower.
The code in sqUnixHeartbeat.c is not a lot nor very complex, it should not be difficult to do...
Then do it! :) Maybe on a branch so we can discuss your change.
Also, what would be the drawbacks besides an increase on the vm size?
I can't think of any drawbacks right now. But I don't think an increased vm size is a big problem, especially now that even Raspberry Pis ship with enough storage. :)