[Glass] Recursion deadlock with TransientRecursionLock

[Dale Henrichs via Glass]

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 
>> <mailto: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/a9f301a0/attachment.html>