kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #37921
Re: GAL canvas deadlock
Hi Jeff-
Am Fr., 12. Okt. 2018 um 13:46 Uhr schrieb Jeff Young <jeff@xxxxxxxxx>:
> That doesn’t work because the lock/unlock calls are in separate routines
> (BeginDrawing() and EndDrawing()).
>
Sorry, I was unclear. There are catches for OpenGL failures that do not
unlock the context if the error thrown is not std::runtime_error. I
believe that the locking conflict is triggered here where an error is
thrown all the way up to GAL, bypassing the unlock and leading to
deadlock. Adding a default catch that unlocks the context before
re-throwing would fix that
> That’s fundamentally unsafe, so I’m adding lockContext() and
> unlockContext() protected methods to the GAL API and a GAL_CONTEXT_LOCKER
> friend class that can be created on the stack. BeginDrawing() will ASSERT
> that the context has indeed been locked.
>
RAII locking is definitely the safest way to go. Lose the stack->lose the
lock.
-S
Follow ups
References
-
GAL canvas deadlock
From: Jeff Young, 2018-10-10
-
Re: GAL canvas deadlock
From: Seth Hillbrand, 2018-10-10
-
Re: GAL canvas deadlock
From: Andrew Lutsenko, 2018-10-10
-
Re: GAL canvas deadlock
From: Seth Hillbrand, 2018-10-10
-
Re: GAL canvas deadlock
From: Andrew Lutsenko, 2018-10-11
-
Re: GAL canvas deadlock
From: Andrew Lutsenko, 2018-10-11
-
Re: GAL canvas deadlock
From: Jeff Young, 2018-10-11
-
Re: GAL canvas deadlock
From: Seth Hillbrand, 2018-10-11
-
Re: GAL canvas deadlock
From: Tomasz Wlostowski, 2018-10-11
-
Re: GAL canvas deadlock
From: Jeff Young, 2018-10-11
-
Re: GAL canvas deadlock
From: Jeff Young, 2018-10-11
-
Re: GAL canvas deadlock
From: Seth Hillbrand, 2018-10-11
-
Re: GAL canvas deadlock
From: Jeff Young, 2018-10-11
-
Re: GAL canvas deadlock
From: Seth Hillbrand, 2018-10-12
-
Re: GAL canvas deadlock
From: Jeff Young, 2018-10-12