Si eso quedó bien. En este momento el #critical:ifError: lo tengo así:
#sasChanged.
^ mutex critical:[
semaphore := SeasidePlatformSupport semaphoreClass
new.
[[response := aBlock on: Error do: anErrorBlock]
ensure: [semaphore signal]]
forkAt: Processor activePriority + 1.
semaphore wait.
response]
y #response es instVar para que perdure y lo de Jhon hace que perdure
al unwind causado por el GC al terminar el proceso forkeado.
El fork lo pusieron los autores y, si bien no hay cualquier tipo de
documentación al respecto, en una prueba de otra cosa dio la
casualidad que vi como trabaja Squeak y Dolphin en esa parte. La
consecuencia inmediata es que sin fork se necesita mucha más RAM, más
o menos 400% más de frames que estando el fork ahi.
En una analogía Star Trek (la captitán Janway estaría de los pelos y
la entiendo más que nunca), las continuations son "lineas temporales".
Allí el fork ese es la tijera que usás para controlar donde deben
empezar los hilos.
Sin analogías, el fork marca el punto desde donde la continuation
comenzó a recordar como se procesa. Si lo haces con el active process
como está en el 2.8a1-eam.529 e, ese proceso nace a la altura del
swazoo que son unos 400% más de frames que si lo haces nacer ahi
mismo. El fork hace que la continuation quede bastante bien acotada al
dominio de la aplicacion seaside y con mínimo costo (RAM).
El forkearlo a una prioridad un puntito mayor que la activa es una
pregunta más interesante solo que no tengo respuesta para ella aún.
Sebastian
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
http://www.clubSmalltalk.org
-~----------~----~----~----~------~----~------~--~---
