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
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
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 andreas.raab@gmx.de:
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
On Wed, 26 Mar 2008 17:42:24 -0700 Andreas Raab andreas.raab@gmx.de 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?
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.
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?
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
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
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 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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Hernán Morales -
Lukas Renggli -
Michael van der Gulik -
Paolo Bonzini -
stephane ducasse