[Vm-dev] [Pharo-dev] Problem with OSSubprocess / signals / heartbeat ?

[Eliot Miranda]

On Thu, Mar 30, 2017 at 4:17 PM, Petr Fischer <petr.fischer at me.com> wrote:

>
> > On Fri, Feb 24, 2017 at 11:57 AM, Holger Freyther <holger at freyther.de>
> wrote:
> > >
> > > Hi!
> > >
> > >> Now, this heartbeat threaded VM is the recommended in the README
> file, and we see that OSSubprocess generates the exact issue stated. The
> main problem remains for the moment since Pharo's default download includes
> not this VM but the itimer one. I talked with Esteban about it and he was
> aware of these two VM flavours, and the reason why we are using the itimer
> one is the need to deploy those permission files in /etc, which makes
> installation a bit less automatic.
> > >
> > > It is not a matter of configuration, e.g. more infrastructure is
> migrated into docker containers (I run the CI with docker containers) and
> even as root inside the container you might not be allowed to use realtime
> priority. And you might not be able to influence how your container is
> being executed.
> > >
> > > holger
> > >
> > > PS: Have you seen the fix David Lewis made to the UnixProcess plugin,
> maybe it already helps with your bug as well?
> >
> > If these two commits work out, the threaded VM may become a viable
> > default option...
> > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/
> 32f321583c69ca27e61ffaff6decc2a3e4b6ca5e
> > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/
> 5418a415e9297f601f6d57ee732fd7fd942da08c
> >
> > cheers -ben
>
> Are these commits immediatelly available in pharo-vm GitHub repository, or
> I need to compile directly from opensmalltalk-vm?
>
> Is it really safe to run VM with normal priority heartbeat?
>

I believe not.  Do something lie spawn a process waiting on a delay that
will interrupt the active process after some time (say 1 second).  Then
have the active process enter a tight loop (e.g. a repeat loop that sends
class to an object).  It is very important that the loop /not/ cause a GC
or a deep call chain so that it doesn't incidentally poll for events and
hence update the clock.  Once the active process is in a tight loop the
delay is effectively disabled because the tight loop effectively shuts out
the heartbeat thread and hence the system never notices that the delay has
expired.



> Thanks! pf
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170330/0b073dcc/attachment.html>