Solved: WAProcess>>critical:ifError problem
Sebastian
in reference to
and after two days of pain I've finally found a solution for that
problem: making the response an instVar so the continuation wont
overwrite the result as nil.
I have not found final evidence but all I've seen indicates that
continuations in Squeak and VisualWorks have some sort of compensation
effect for temps which Dolphin has not. So they wont overwrite the
temp which receives the answer of the block evaluation with nil as
Dolphin does.
The code I'm using now is
WAProcessMonitor>>critical: aBlock ifError: anErrorBlock
^ mutex critical:[
semaphore := SeasidePlatformSupport semaphoreClass new.
process := [[response := aBlock on: Error do: anErrorBlock]
ensure: [semaphore signal]] fork.
semaphore wait.
process := nil.
response].
For the record the previous was:
| value |
mutex critical:
[process := Processor activeProcess.
[value := aBlock on: Error do: anErrorBlock] ensure: [process :=
nil]
].
^ value
which is a workaround which uses more than 400% of additional RAM
unnecessarily (because the continuation will copy the process to its
born far there in swazoo). That fork is cutting the copy just where it
is needed (a pity those subtleties aren't documented).
I hope this is one problem less for Dolphin Seasiders,
Cheers,
Sebastian
Malbs
Sebastian
> Nice find/fix!
Subject magic ;)
Also check:
cheers,
Sebastian
macta
> and after two days of pain I've finally found a solution for that
> problem: making the response an instVar so the continuation
> wontoverwrite the result as nil.
Any chance you could put your Seaside corrections into the global repository that David has now provided?
We need to get better at having a global place with all latest fixes (I'm equally guilty as well)
Tim
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo