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
-~----------~----~----~----~------~----~------~--~---

Responder a