[Swift-user] what is wrong with restart5.swift?

[Ben Clifford]

On Sun, 25 May 2008, Mihael Hategan wrote:

> Should be fixed in r2004.

runs ok without restarts using r2004.

I put it in tests/misc/restart5.sh, as three runs:

  i) runs without restart, expecing a succesful end.
  ii) run with B set to fail and A and C set to succeed, expecting a fail
  iii) restart the run from ii) with A set to fail and B and C set to 
succeed, expecting success.

This should check that all of the A jobs get run the first time and that 
their output is logged for restart successfully (because A cannot be 
called in part iii).

During my viewing of Eurovision last night, I was poking round with some 
of the stuff I talked about wrt scope identification.

As far as I can tell, at the moment, the way that 
VDLFunction.getThreadPrefix works at the moment is roughly the "right 
thing" to do as far as that is concerned:

New SwiftScript scopes are always represented in Karajan as a new thread; 
and those threads are labelled by their position in the source code 
(because they get numbered in accordance with their position in a 
<parallel> block, so this is invariant wrt restarts) or, if a stack frame 
has a $ variable (the foreach iteration variable container) then the 
position in the array being iterated is used instead of the thread number.

This is pretty much the behaviour I think is desirable (modulo the fact 
that this implementation probably doesn't work for iterate{} but I think 
that is easily fixable).

So I think filename based concurrent mapping works with restarts 
(modulo iterate{}).

I also think that is(was?) the only correctness problem with restarts at 
the moment.

--