[Glass] Recursion deadlock with TransientRecursionLock

[Johan Brichau via Glass]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150414/a94558b8/attachment.html>