On Tue, Apr 28, 2015 at 5:00 PM, Levente Uzonyi leves@elte.hu wrote:
If there's an error signaled from aBlock, and the default error handler is activated (see UnhandledError >> #defaultAction), then the process will be suspended (see Debugger class >> #morphicOpenOn:context:label:contents:fullView:) while it's inside the AccessLock mutex's critical section. The (new) UI process will try to display a debugger. To do that, it will try to read the values of various preferences, but the suspended process is holding the mutex, so it'll wait forever. This results in an image lockup, because using Alt+. (Cmd+. on mac) will also try to open a debugger. This is why aBlock must be evaluated outside of the AccessLock mutex's critical section.
Okay, the newer one is probably safer because #at:ifPresent: *probably* won't get an error, but theoretically it still could, leaving the image locked for the very same reason.
So Eliots suggestion is sounding good -- why do something like preferences need to be guarded on access? It seems not that important...