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

> What is actually particularly hard is having one thread modify the instructions being executed by another thread
> in real time. Now, if you were to halt the second thread whose code is being modified at a known place then
> that I can understand. But while it is executing? That just seems like an amazingly hairy problem.

That would be hard. But I would strongly suspect the Ptolemy project wasn't that crazy.
My conjecture is that they probably had defined stopping points at procedure call and
return, and that the granularity of interactive program modification would be to
atomically replace a set of procedure implementations with new versions. Which would
involve roughly:

a) mark the old procedure versions as obsolete. Any threads attempting to call
an obsolete procedure from a non-obsolete procedure are halted.

b) wait until all current executions of obsolete procedures are finished

c) allow all halted threads to continue, using the new procedure versions

... but it can't be quite that simple, because when you halt a thread for a
version change, it might be holding some resource (e.g. a mutex or semaphore)
which is needed by some thread running obsolete code. So halting the
threads might introduce a deadlock which wasn't in the either the original
or the new version of the actual program. So you might need a way to detect
such deadlock and recover (e.g. by letting one or more of the threads involved
in the deadlock call obsolete routines until they release the resource
involved in the deadlock).

Definitely non-trivial. But not as "amazingly hairy" as what you've guessed.