Hi Jaromir,

> Real life examples? I'm thinking parallel computing where one process can
> terminate while another one running in parallel might still want to resume
> it assuming or hoping it is only suspended (without an explicit check that
> would raise an exception). Just a thought...

Hm, in this example, you could also use a critical section to check whether
the process is terminated and then handle it respectively, couldn't you? I
still think we need a better example to conduct this discussion. Still, I
don't have great parallel programming experiences, so this is just a naive
assumption. Probably someone else can give their statement? :-)

> 2. Readability of the code (newProcess's logic isn't easy to decode)

Yes, this is probably your most important reason so far. :-)

> 3. Easy way to spot a terminated process while debugging :)
> (suspendedContext = Process>>#terminated)

You could also improve the #printString implementation of Process to reach
this goal. :-)

> However, replacing:
>                 ctxt setSender: nil receiver: self method:
> (Process>>#terminated) arguments: {}.
> 
> with:
>                 ctxt := Context sender: nil receiver: self method:
> (Process>>#terminated) arguments: {}
> doesn't update the stack frame because nothing happens

After taking a second look at this part of your changeset ... Why do you
need to manipulate the stack *after* terminating the process? Wouldn't it be
possible to set the sender of the prior bottom context to the #terminated
method (provided that it does not already point to that) so that #popTo:
will automatically activate this context unless the termination was aborted?
Pseudo:

		(ctxt bottomContext method pragmaAt: #isTerminated) ifNil:
		        [ctxt bottomContext privSender: (Context sender: nil receiver:
self method: Process >> #terminated)].
arguments: {}
		ctxt := self popTo: suspendedContext bottomContext.
		(ctxt bottomContext method pragmaAt: #isTerminated) ifNil:
			[self debug: ctxt title: 'Unwind error during termination'].

> It's actually a matter of a policy: do we want users to create processes
> other than the "newProcess" way?

That is an interesting question. When designing a new system, I would
definitively agree, just because it makes it easier to distinguish between
corrupted processes and valid terminated processes. Another aspect is
compatibility, and at the very least Process class >> #forContext:priority:
is a public instance creation method which we would need to deprecate for
public usage (with the exception of #newProcess...). The next Squeak release
will have a new major version number, but still, I think we should not
destroy bridges behind us and limit compatibility more than necessary.

That being said ... I don't know, again. Third opinions desired!

> I used a new pragma instead of hardcoding the class and the selector of
> the terminal method

I just saw that, but what's the reason for it? Pragmas to mark methods are
usually meant as extension points. So I could define any other method with
this pragma anywhere in my image and suspending a process in this method
would magically make it be displayed as terminated. Do we really need this?
Do you have any concrete example where Process >> #terminated does not
suffice? :-)

I have just another question, being completely agnostic of the relevant VM
implementation. How does the VM know when a process can be
gargabe-collected? I don't think it will invoke the image-side #isTerminated
check, so it will probably define its own logic for checking termination. If
this is the case, we should be very careful to keep both implementation in
sync to avoid dangling process instances in the image.

Best,
Christoph



-----
Carpe Squeak!
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html