Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Resuming a terminated process

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Andreas.Raab

[squeak-dev] Resuming a terminated process

Hi -

Here is an interesting one:

p := [self inform: 'Oh, noes'] fork.
p terminate.
p resume.

This works fine on all Squeak versions that I've tried it on. Do people
agree that this is a bug and should raise an error or is there any
reason why it should behave the way it does right now?

Note that the above also works for:

p := [self inform: 'Oh, noes'] newProcess.
p terminate.
p resume.
p terminate.
p resume.

etc.

Cheers,
- Andreas

Andreas.Raab

[squeak-dev] Re: Resuming a terminated process

Oh, and one more interesting issue:

[] newProcess terminate isTerminated ==> false

I think it's time to take this up with a few SUnit tests. How about these:

self assert: [] fork terminate isTerminated.
self assert: [] newProcess terminate isTerminated.

self should:[ [] fork terminate resume ] raise: Error.
self should:[ [] newProcess terminate resume ] raise: Error.

Any other interesting ones?

Cheers,
- Andreas

Andreas Raab wrote:

> Hi -
>
> Here is an interesting one:
>
> p := [self inform: 'Oh, noes'] fork.
> p terminate.
> p resume.
>
> This works fine on all Squeak versions that I've tried it on. Do people
> agree that this is a bug and should raise an error or is there any
> reason why it should behave the way it does right now?
>
> Note that the above also works for:
>
> p := [self inform: 'Oh, noes'] newProcess.
> p terminate.
> p resume.
> p terminate.
> p resume.
>
> etc.
>
> Cheers,
> - Andreas
>
>
>

hernanmd

Re: [squeak-dev] Re: Resuming a terminated process

Maybe these ones

(['Testing...' printString] forkAt: Processor lowestPriority) terminate resume.
(['Testing...' printString] forkAt: Processor systemBackgroundPriority) terminate resume.
(['Testing...' printString] forkAt: Processor userBackgroundPriority) terminate resume.
(['Testing...' printString] forkAt: Processor userSchedulingPriority) terminate resume.

(['Testing...' printString] forkAt: Processor userInterruptPriority) terminate resume.
(['Testing...' printString] forkAt: Processor lowIOPriority) terminate resume.
(['Testing...' printString] forkAt: Processor highIOPriority) terminate resume.
(['Testing...' printString] forkAt: Processor highestPriority) terminate resume.

2008/3/26, Andreas Raab <[hidden email]>:

Oh, and one more interesting issue:

   [] newProcess terminate isTerminated ==> false

I think it's time to take this up with a few SUnit tests. How about these:

   self assert: [] fork terminate isTerminated.
   self assert: [] newProcess terminate isTerminated.

   self should:[ [] fork terminate resume ] raise: Error.
   self should:[ [] newProcess terminate resume ] raise: Error.

Any other interesting ones?

Cheers,

   - Andreas

Andreas Raab wrote:
> Hi -
>
> Here is an interesting one:
>
>   p := [self inform: 'Oh, noes'] fork.
>   p terminate.
>   p resume.
>
> This works fine on all Squeak versions that I've tried it on. Do people
> agree that this is a bug and should raise an error or is there any
> reason why it should behave the way it does right now?
>
> Note that the above also works for:
>
>   p := [self inform: 'Oh, noes'] newProcess.
>   p terminate.
>   p resume.
>   p terminate.
>   p resume.
>
> etc.
>
> Cheers,
>   - Andreas
>
>
>

Michael van der Gulik-2

Re: [squeak-dev] Resuming a terminated process

In reply to this post by Andreas.Raab

On Wed, 26 Mar 2008 17:42:24 -0700
Andreas Raab <[hidden email]> wrote:

Argh! A zombie process!

After "p terminate", p should be a terminated process. Terminated processes are dead, and I like my dead processes to stay dead.

Gulik.

--
Michael van der Gulik <[hidden email]>

Paolo Bonzini-2

[squeak-dev] Re: Resuming a terminated process

In reply to this post by Andreas.Raab

Andreas Raab wrote:

I don't know if this is the case, but I can see why this happens:
terminating is not something that happens instantaneously when you send
#terminate. In particular, it could take a while if p has a low priority.

I don't remember offhand is Squeak has a #primTerminate method, or
something like that, that is basically

suspendedContext := nil.
self suspend

If it has, allowing to resume after a #primTerminate would definitely be
a bug.

Paolo

stephane ducasse

Re: [squeak-dev] Resuming a terminated process

In reply to this post by Andreas.Raab

Andreas

Did you see the problems reported after integrated the last semaphores
fixed in 3.9.1?
Did you get similar problems?

I'm about to write a couple of chapters on Squeak by Example volume two
on concurrency abstractions in Squeak/Smalltalk and I will learn a lot
in the process on my limits :)
I hope that I will get feedback on all the silly things I will write.
Now it would be good to have some fixed version on all the issues
raised recently.
At the bugs and idioms levels.

Stef

On Mar 27, 2008, at 1:42 AM, Andreas Raab wrote:

> Hi -
>
> Here is an interesting one:
>
> p := [self inform: 'Oh, noes'] fork.
> p terminate.
> p resume.
>
> This works fine on all Squeak versions that I've tried it on. Do
> people agree that this is a bug and should raise an error or is
> there any reason why it should behave the way it does right now?
>
> Note that the above also works for:
>
> p := [self inform: 'Oh, noes'] newProcess.
> p terminate.
> p resume.
> p terminate.
> p resume.
>
> etc.
>
> Cheers,
> - Andreas
>
>
>

Lukas Renggli

Re: [squeak-dev] Resuming a terminated process

> Did you see the problems reported after integrated the last semaphores
> fixed in 3.9.1?

Just as a side-note, but the inst-var errorHandler and its accessors
#errorHandler and #errorHandler: does not seem to be used at all. Is
there anything non-obvious here?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Andreas.Raab

[squeak-dev] Re: Resuming a terminated process

Lukas Renggli wrote:
>> Did you see the problems reported after integrated the last semaphores
>> fixed in 3.9.1?
>
> Just as a side-note, but the inst-var errorHandler and its accessors
> #errorHandler and #errorHandler: does not seem to be used at all. Is
> there anything non-obvious here?

A left-over from the early days when there wasn't proper exception
handling. In Squeak 2.x you'll find BlockContext>>ifError: doing, e.g.,

BlockContext>>ifError: errorHandlerBlock
| lastHandler val activeProcess |
activeProcess _ Processor activeProcess.
lastHandler _ activeProcess errorHandler.
activeProcess errorHandler: [:aString :aReceiver |
activeProcess errorHandler: lastHandler.
^ errorHandlerBlock value: aString value: aReceiver].
val _ self value.
activeProcess errorHandler: lastHandler.
^ val

Cheers,
- Andreas