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.
To reproduce the error, just evaluate this expression (but keep in mind that your image will not be able to respond anymore):
Preferences preferenceAt: #'no such preference' ifAbsent: [ self error ]
Levente
On Tue, 28 Apr 2015, Chris Muller wrote:
Wait, the newer one has a non-local return in it, but Mutext>>#critical: has an ensure: in it anyway, so maybe I don't see the problem..?
On Tue, Apr 28, 2015 at 2:43 PM, Chris Muller asqueaker@gmail.com wrote:
The above change restores the old behavior of locking up the image, so it should be reverted. An additional comment explaininng why aBlock must not be evaluated inside the argument of #accessDictionaryOfPreferencesIn: would be helpful.
Ahh, because aBlock might have a non-local return in it, leaving the Mutex unsignaled (and critical unenterable), is that right?
Took me a minute to see that problem.
Okay, I'll revert that method if no one else does by my next commit..
It would be even better to finally get rid of DictionaryOfPreferences.
Levente