On 16/10/2007, Paolo Bonzini <bonzini at gnu.org> wrote:
> Igor Stasenko wrote:
> > Also note, that because we have only the 'soft' terminate, this leads
> > to appearance of some evil code like:
> >
> > block := [ [ true] whileTrue: [ ... ] ].
>
> where?
>
> > or even #addOnTerminate: block , which will add a block to a list of
> > blocks which will be evaluated when process is terminating.
>  >
> > Also, i not agree that terminate must be connected with exceptions.
>
> Also in Java termination trigger an exception.  Here, the point is that
> abrupt termination of a process is a nasty thing, something that's going
> to cause bugs unless you take special measures (witness the mess that is
> done in Delay to avoid half-updating the data structures), and the
> process must know about it!  A hard termination must only be used as a
> last measure, really.
>
> If you use these termination blocks heavily, you will soon want to
> remove them.  And sooner or later you realize that the best way to
> remove them is to store their information somewhere on the context chain
> which is where #ensure: and exceptions put it.
>
> The fact that process execution flow *can* be controlled by an exception
> is also hinted by a method such as Process>>#signalException:, which
> will even wake up a process temporarily for the sake of signalling that
> exception.  (Other Smalltalks, such as VA and GNU, have a more generic
> #queueInterrupt: method that takes a block, but Squeak's solution is
> also very elegant).
>
> Paolo

One or other way, we need to have control on how to react to process
termination, so developer can put a finalization code for such case
(not for general case as with #ensure:), because difference, as
illustrated with Semaphore>>critical:/wait is great.

But even with your case there are pitfalls, i can put the exception
catching code and omit  'sig pass', breaking the safe termination
flow.
[ ]  on: ProcessBeingTerminated
   do: [:sig |
do something.
" sig pass"
].

I don't know, maybe we can come up with more safe scheme, which
provides same semantics and also way to control termination, but be
simple at same time and not requiring from developer to know much of
details (like putting "sig pass")?

Also, i don't know much details on how squeak handles exceptions.
Suppose i signaled exception, triggering stack unwinding, but
somewhere in the middle i put something in #ensure: block which causes
new exception. What happens in this case?
Does process stack continue unwinding using exception generated first,
or it will be replaced by new one?

And for me, still is unclear, how to guard a process which terminates
other process to not be terminated until it finishes termination of
other process, which is critical to fulfill the 'soft termination'
semantics?


-- 
Best regards,
Igor Stasenko AKA sig.