(Execution) Termination bit, Alternation bit.

[Skybuck Flying]

"Richard Damon"  wrote in message news:QXSdy.6634$QG6.5135 at fx31.iad...

On 12/21/15 7:40 AM, Skybuck Flying wrote:
> The original idea I posted is less about sending a signal to another
> processor.
>
> It is more about how to break out of an instruction sequence.
>
> Example of problem:
[snip]
> Bye,
>   Skybuck.

"
The issue is that if your threads are doing real work, the cleanup
needed at each point keep the environment clean for other threads likely
varies. Just arbitrarily stopping or blindly going off to something else
is very apt to create problems.

Some languages can be better at automatically cleaning up for you, these
will tend to be languages that support some form of exception
processing, as that tends to need similar support. You abort can be
treated as a type of exception that is automatically thrown when signaled.

The problem here is that most programs, while they can handle exceptions
in many spots, have some spots where exceptions will cause problems,
especially in code that is directly managing the resources. Thus, you
still need to have some definition of where to check for the breaks.
"

I can imagine that arbitrarily terminating somewhere can lead to problems 
for example in memory clean up code, where then memory leaks might occur.

Though applications do sometimes seem to clean up anyway.

One idea which immediatly comes to mind to fix this problem is to offer a 
"PushTerminationFlag" onto stack and then a "ClearTerminationFlag" 
instruction.

Then a code section can be executed without breaking or terminating.

Once that's done the code would then call "PopTerminationFlag".

At least this offers some protection against arbitrarely breaking code 
sections.

Bye,
  Skybuck.