On Aug 22, 10:10 am, GallegO <[EMAIL PROTECTED]> wrote:
> Hola:
>
> En un momento tuvimos algunos problemas que no eran tales con la
> implementación de Continuation de Dolphin.
> Luego de darle muchas vueltas deducimos que estaba bien lo que hacían
> (esas copias que te huelen mal también nos olían mal a nosotros). Eso lo
> implementó la gente de ObjectArts. Puede que para esa implementación
> haya que modificar en algún método la implementación de Seaside, pero me
> parece un poco power ir por el lado de modificar los Continuations.
> Podes terminar peor que después de una botella de whisky :P.
Si, totalmente.
> Vos decis que no anda de la misma forma que en Squeak y VW?, eso es lo
> que entiendo.
Para no empeorar la confusion vamos paso a paso. No es que *quiera*
modificar las Continuations.
Lo primero que quiero es exponer cualquier diferencia de
comportamiento entre las continuations de Dolphin y Squeak o
VisualWorks. Eso si es que realmente hay esas diferencias. Esto es lo
primero.
Teniendo eso claro, o sea cuales son y por qué se dan entonces
estaremos en condiciones mínimas de pensar qué hacer en Dolphin.
Lo mejor que podría pasar es que se revele un bug (o bien algo
considerado feature pase a clasificar como bug por tomar como
referenca Squeak y VW). Si se revela lo publicamos con tests en la
lista Dolphin y vemos que reacción hay.
Mi idea es hacerlo en los 3: squeak vw y dolphin y publicar el codigo
de los tests así no hay pérdidas de tiempo en discusiones sobre como
debería ser ya que este tema fácilmente genera mucha confusión.
>
> Por otro lado, y ya habiendo olvidado bastante de Seaside, habia una
> forma de que al darle al back button te expiraba esa acción por lo que
> sería imposible ejecutar nuevamente esa página. Esto te funciona mal? No
> deberías implementar así las transacciones/excepciones?
>
Claro vos te referís a la transaction del propio seaside para prevenir
el backbutton en acciones de la app que son irreversibles.
Aclaro: las transacciones que yo digo no son del workflow de la app.
Son, en cambio, de la odb (los commits) y están a nivel del request
así:
1. BlahSession>>incomingRequest: aRequest
...
^ monitor
critical: [self responseForRequest: aRequest]
ifError: [ :error | self errorHandler internalError: error ].
2. BlahSession>>responseForRequest: aRequest
currentRequest := aRequest.
^ self withEscapeContinuation: [
WACurrentSession
use: self
during: [
self withErrorHandler: [
self performRequest: aRequest ] ] ]
3. BlahSession>>withEscapeContinuation: aBlock
| response |
^ self database execute:
[response := super withEscapeContinuation: aBlock.
response ifNil: [ODBCannotLockObject signal: 'Re-signalled from
ODBSession'].
response status = '500' ifTrue: [ODBSInternalError signal].
response]
por lo que toda la parte de flujo, los componentes etc etc se
resuelven dentro del #responseForRequest del paso 2 que se ejecuta
dentro del super withEscapeContinuation: que ves en el codigo que puse
en 3.
> Tenes ya algún workspace para probar el mal funcionamiento?
>
No. Ahora estoy laburando sobre la app pero a la noche me voy a tomar
un rato para hacerlo. Mientras voy pensando para ordenar ideas porque
no se que diferencia de comportamiento buscar entre dolphin y los
otros como para priorizar tratar de exponerla.
Si se te ocurre algo cualquier aporte is most welcome. Hasta ahora
tenemos el tema del bloque ensure: que parecería comportarse
correctamente pero sorprende porque se ejecuta una cantidad de veces
que no es intuitiva. Sin embargo Esteban al portar tuvo el problema de
que no retornaban el valor del bloque evaluado en #critical:ifError:
(motivo de su post en dolphin). Si el squeak and/or VW llegaran a
hacerlo diferente o diferente cantidad de veces ya sería un primer
test a desarrollar.
El otro que se me ocurrió es el que devuelva el valor del bloque
evaluado, problema al que Esteban le encontró un workarround pero con
continuations en el medio no me atrevo a decir que es absolutamente
equivalente a los autores seaside (en squeak y vw el bloque se evalua
en un fork y en el workarround en el activeProcess).
> Buena pregunta lo del thisContext, no es tan directo de caminar como VW
> o Squeak. Desde un browser menú Method>Browse other>containingText
> "thisContext" ahí te sale #topFrame, de donde ves cómo se usan las
> instancias de StackFrame.
> Fijate Object>>shouldNotImplement como esta implementado, ahí ves un
> pequeño eslabón en la cadena.
>
> Saludos
> GallegO
>
Lo de #topFrame lo habia visto pero lo del #shouldNotImplement no.
Gracias por la referencia. Lo había visto porque en una imagen aparte
hice un approach naive de implementar la continuation igual a squeak
sin usar el stackframe copier de dolphin (no tengo pruebas aun pero
sospecho que la forma de copiar del squeak compensa algo incluso
pareciendo quiza menos rigurosa, me parecio mas shallow que el
stackframe copier).
En esa prueba falle miserablemente cuando me topé con que no encajan
exactamente el concepto de stackframe usado por dolphin con el de
methodcontext squeak/vw. No obstante se parecen mucho pero tengo que
reconocer que esto del stack frame son tierras nuevas para mi.
En cuanto tenga algo publico,
Saludos,
Sebastian
> Sebastian escribió:
>
> > Vi que la clase Continuation en VisualWorks inicializa igualita a
> > Squeak en cambio en Dolphin es bien diferente.
>
> > Entonces pregunta básica rebobinando..
>
> > Que posibilidades hay de implementar la continuation también igual en
> > Dolphin?
>
> > Además de ser lo que el/los autores hicieron, mi nariz me dice que en
> > esa forma de copiar esta la clave.
>
> > Sebastian
> > PD: El thisContext de Dolphin retorna un numero en lugar de una
> > instancia de methodContext como VW y Squeak. Como hago para obtener el
> > methodContext que corresponde a thisContext?
>
> > On Aug 21, 8:51 pm, Sebastian <[EMAIL PROTECTED]> wrote:
>
> >> El problea más grave es que acciones ejecutan más veces que lo que
> >> deberían. Si bien el uso de la odb reveló el problema, este
> >> comportamiento puede traer problemas impredecibles para aplicaciones
> >> Seaside.
>
> >> Aún en la versión 2.8a1 eam 529 e se pueden ver cosas como esta:
> >> (extraido de un logueo al transcript)
>
> >> Free clients: 4
> >> Get odb client: 52791 from process HTTPConnection>>interact
> >> Return odb client: 52791 from process HTTPConnection>>interact
> >> Return odb client: 52791 from process Copy of 349:Copy of
> >> 340:HTTPConnection>>interact
> >> Redundant return! (mutex violation?)
>
> >> el numero de client es el hash de la odb en el pool. El pool como
> >> decia antes esta protegido por un semaforo for mutual exclusion y el
> >> get y el return se ejecutan dentro de un critical para que justamente
> >> este garantizado que dos procesos no puedan tomar un mismo cliente.
> >> Nota: el "Get odb..." se imprime despues que terminó el critical.
>
> >> El proceso que es copia del 349 y que viene de la EscapeContinuation
> >> no deberia haber tomado la odb.
>
> >> Es plausible que no la haya tomado y la conozca porque "behind the
> >> scenes" la continuation se la copió (cosa que no se como confirmar).
> >> Si este fuera el caso entonces estaría más claro como funciona el bug
> >> de ejecutar cosas dos veces. Para un escenario como este hago la
> >> siguiente pregunta:
> >> será que las continuations de Squeak hacen algo para compensar esa
> >> doble ejecución? (quizá en la forma de copiar el proceso?)
> >> idem VW? (ya lo estoy probando a ver que tal)
> >> será que el cógo original de #critical:ifError:, que evalúa el bloque
> >> en un fork y espera el resultado, no hace eso justamente como parte de
> >> la compensación?
>
> >> Voy a estar haciendo algo de codigo para poner esto en evidencia y ver
> >> si hace lo mismo VW
>
> >> saludos,
>
> >> Sebastian
>
> >> On Aug 21, 4:06 pm, Sebastian <[EMAIL PROTECTED]> wrote:
>
> >>> Ah bueno! eso explica un montón de cosas. Incluída la copia del
> >>> semaforo en un estado anterior y que permite ejecutar la accion
> >>> protegida cuando deberia frenarse. No es loco porque justamente
> >>> continuations es ir para atras y para adelante en el tiempo. Esto se
> >>> esta pareciendo peligrosamente a los expedientes X de la computacion.
> >>> Concretamente eso explica el doble returnClient: y doble commit: a la
> >>> transacción.
> >>> Voy a digerir un poco todo esto
>
> >>> gracias totales por la referencia Esteban
>
> >>> Sebastian
>
> >>> On Aug 21, 3:28 pm, "Esteban A. Maringolo" <[EMAIL PROTECTED]>
> >>> wrote:
>
> >>>> Sebastián:
>
> >>>> Podes tratar de revivir el thread:
> >>>> <http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_thr...>
>
> >>>> Suerte :-|
>
> >>>> Esteban A. Maringolo
>
> >>>> 2008/8/21 Sebastian <[EMAIL PROTECTED]>:
>
> >>>>> Hola gente,
>
> >>>>> estoy atras de un problema un tanto inusual por decir algo.
> >>>>> Mi objetivo es usar Seaside en dolphin workers y que la sesión wrapee
> >>>>> con una transacción la respuesta del request (los porqués de esto son
> >>>>> un poquillo off-topic pero el que quiera ver una referencia puede ver
> >>>>> OmniSupport en squeaksource.com). Quedaría (simplificando el exception
> >>>>> handling) algo así:
>
> >>>>> BlahSession>>withEscapeContinuation: aBlock
> >>>>> | response |
>
> >>>>> ^ self database commit:
> >>>>> [response := super withEscapeContinuation: aBlock.
> >>>>> response ifNil: [ODBCannotLockObject signal:
> >>>>> 'Re-signalled from
> >>>>> ODBSession'].
> >>>>> response status = '500' ifTrue: [ODBSInternalError
> >>>>> signal].
> >>>>> response]
>
> >>>>> Entonces todo lo que la app seaside requiere para resolver ese request
> >>>>> se hace dentro de esa transacción (sacada de un pool para aumentar
> >>>>> availability).
>
> >>>>> El problema todavía no lo conozco bien pero detallo lo que vi:
> >>>>> se ve de dos formas, 1 a veces se retornan conexiones al pool que ya
> >>>>> habían sido retornadas (notar que el getClient y el returnClient: del
> >>>>> pool están protegidos con un mutex) y 2 a veces se hace un commit a
> >>>>> una transacción que ya le hicieron commit.
>
> >>>>> Lo que parece estar pasando es que alguien no respeta un #critical:
> >>>>> cosa que sería totalmente chiflada a menos que continuations
> >>>>> estuvieran en el medio (son lo más loco que vi en ST hasta hoy).
>
> >>>>> Destaco que Esteban para portar el Seaside a Dolphin tuvo que cambiar
> >>>>> WAProcessMonitor>>critical:ifError:
>
> >>>>> | value |
> >>>>> #eamChanged.
> >>>>> mutex critical:
> >>>>> [process := Processor activeProcess.
> >>>>> [value := aBlock on: Error do: anErrorBlock] ensure:
> >>>>> [process :=
> >>>>> nil]
> >>>>> ].
> >>>>> ^ value
>
> >>>>> en lugar del original de squeak que, como referencia, es:
>
> >>>>> | value |
> >>>>> mutex critical: [
> >>>>> semaphore := SeasidePlatformSupport semaphoreClass new.
> >>>>> process := [
> >>>>> [ value := aBlock on: Error do: anErrorBlock ]
> >>>>> ensure: [ semaphore signal ] ] fork.
> >>>>> semaphore wait ].
> >>>>> process := nil.
> >>>>> ^ value
>
> >>>>> Si bien la versión Esteban anda, no termino de convencerme que estén
> >>>>> haciendo lo mismo con los procesos. Todavía no veo como pero ni pude
> >>>>> probarlo pero parecería posible que este habiendo algo que confunde
> >>>>> incluso al critical.
>
> >>>>> Si alguien tiene una idea de como probar en el workspace que dos
> >>>>> procesos provenientes de continuations respetan normalmente el
> >>>>> critical me sería de gran ayuda. Hace dos días que empecé a
> >>>>> incursionar en las profundidades de las Continuations y todavía no
> >>>>> termino entenderlas.
>
> >>>>> Algun paper que ayude para recomendar?
>
> >>>>> gracias,
>
> >>>>> 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
-~----------~----~----~----~------~----~------~--~---
