[Glass] Recursion deadlock with TransientRecursionLock

[Otto Behrens via Glass]

Thanks guys, this helps. Way too deep for me to follow properly, but
this has been bothering us.

We disabled the object log a long time ago, with the hope that we'll
get fewer problems. (by overriding addToLog to do nothing).

On Tue, Apr 14, 2015 at 3:31 PM, Dale Henrichs via Glass
<glass at lists.gemtalksystems.com> wrote:
> Yep, that's my take on it ...
>
>
> On 4/13/15 10:32 PM, Johan Brichau wrote:
>
>
> On 13 Apr 2015, at 21:53, Dale Henrichs via Glass
> <glass at lists.gemtalksystems.com> wrote:
>
> I just looked and there used to be (in 2.8?) a fork at the session level and
> that fork insulated the rest of the handling stack (which is pretty much
> unchanged since 2.8)  from process perturbations caused by continuations ...
> with the introduction of partial continuations that occurred in 3.0(?) the
> fork was eliminated ... so these days the process can (and apparently does)
> change all of the time during `(resultBlock value: aNativeRequest)` and as
> you point out this doesn't matter unless a commit conflict occurs during the
> handling of a continuation ....
>
>
> For what I understand, the "root of all evil" is in the
> WAPartialContinuation class doing calls to
> GsProcess>>partialContinuationFromLevel:to: and
> GsProcess>>installPartialContinuation:atLevel:value:
> I assume (because there is a primitive call there) that this switches the
> GsProcess object for the active process. So, it’s never passing through any
> fork or other process switching in the ProcessorScheduler, from what I can
> make of it.
>
> Yes, glad I finally found this one… those crashes have been bothering me for
> years already!!
>
> Johan
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>