Re: Shutting down VatTP

On Sun, 2010-10-17 at 13:16 +0100, Thomas Leonard wrote: 
> On 15 October 2010 18:19, Kevin Reid <kpreid-M/[email protected]> wrote:
> > On Oct 15, 2010, at 11:50, Thomas Leonard wrote:
> >
> >> It's quite useful to be able to restart a vat without having to
> >> restart
> >> the whole JVM. This requires shutting down the listing sockets (among
> >> other things), so that the new vat can start listening on the existing
> >> socket.
> >>
> >> What's the best way to do this? I got it working in a hacky way like
> >> this:
> >>
> >> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/8b94a34e9e45df1ea3cdf933bfe3c96dedb2c317
> >
> > This is wrong: once onTheAir, the introducer should be safe to expose
> > to untrusted clients that you're not bit-confining (that is, be
> > defensively consistent): giving it a shutdown operation breaks this.
> >
> >> - How should this be exposed to E code?
> > [...]
> >> - Should vat.orderlyShutdown do this automatically?
> >
> > It seems to me that orderlyShutdown of a vat should shut down its
> > Pluribus stack. I see no reason to do otherwise, and I am surprised it
> > doesn't do so already.
> 
> I guess that CapTP should register itself as a DeadManSwitch with the
> introducer's Runner and shut down then. But I don't see how to do
> this:
> 
> - Runner.addDeadManSwitch is "protected", and I can't see how to get
> the Runner anyway.
> - Switches are only notified if they're bootrefs to another (non-dead) vat.
> 
> Nothing appears to be calling addDeadManSwitch currently. What's it for?

OK, new attempt:

1. Added static Runner.whenDead() method to register a deadManSwitch

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/ec0d0c82d7f23028ed34a2b97d35fd1ce92068fc

This adds a new deadManSwitch to the current runner. Because it's the
current runner, it should automatically be a bootref if the handler is
in a different vat.

If it's not a boot-ref, we now invoke it synchronously (instead of
ignoring it). This is mainly so it can be used from ListenThread, but it
might also be useful to let E code register a handler to run in the same
vat (although obviously it won't be able to queue any more events on the
same runner).

It still calls __reactToLostClient when triggered. Is this a sensible
method to call, or should it invoke "run"?


2. Close vattp listening sockets when runner dies

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/be0ab0dfc214e33b40c7894c3d3aecb274e9a2b1

Uses the new mechanism to register a handler.

Note that it now closes the listening socket immediately (triggering the
accept() call in the listener thread to throw an exception) rather than
just flagging that the socket should be closed. I don't know whether
there are portability issues here, but it seems useful to close the
socket synchronously in the case where we want to restart listening
immediately.

By the way, what's the point of the UserThread created by each
ListenThread?  The comment says it's to prevent the program exiting
when there are no other threads, but wouldn't it make more sense to
exit in that case anyway?


I also made some updates to updoc to add a "?? shutdown vat <X>"
directive:

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/26846a6db09aab27ee44f3472c50c0daa1c78b01

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/9cb9c0dd8bec0d4ed422ddfabcbe023a84d518f4

To make it work, I had to change DeadRunner to process
__whenMoreResolved messages (by resolving to the shutdown problem
mostly, or by resolving to null if the message was sent to null; this
allows you to resolve shutdown's return value):

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/2dd2ee9aaa37cfe6239fe0299a7fdfece7ba34a2

All of this is very hacky. You often get a load of these, even though
the tests work:

comm: Error while calling net.vattp.data.DataCommThunk@34f3d942 Type=4
--vvvv--
makeEvaluator shutdown


Suggestions on a better approach welcome...


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk