Symmetry (someone.delete@this.somewhere.com) on May 16, 2013 1:14 pm wrote:

> I think that "modification of concurrent programs via a graphical user interface while those concurrent
> programs were executing" are a lot more than just "non-trivial". Figuring out what part of an arbitrary
> executing program you can alter at a given time honestly sounds about as hard as solving the halting problem
> to me. This is far harder than any concurrency I've ever worked with or even previously heard of.

I think you're assuming the "arbitrary executing program" part: it seem much more
likely that the programs involved were compiled/interpreted with suitable hooks
allowing program execution to be traced (so that the system knows which threads
are executing what code at any point in time), and threads to be halted when
necessary (at points when continuing would allow them to see a transient inconsistent
program state). With those hooks, it becomes not so different from the problem of
updating a database with complex atomic transactions, while ensuring that no client
ever sees an inconsistent state.