[Vm-dev] Unix heartbeat thread vs itimer

Fabio Niephaus lists at fniephaus.com
Fri Jan 6 16:49:29 UTC 2017


On Fri, Jan 6, 2017 at 3:44 PM 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.
>

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


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


More information about the Vm-dev mailing list