Intermittent errors in find-presentation-translators due to non-thread-safe code

[john-a-carroll]

I'm getting occasional (and unfortunately not reliably reproducible) errors when moving the mouse over the presentations (= menu items) in a menu popped up via menu-choose. The really annoying thing from a usability point of view is that once the error has happened for a particular menu, it happens every subsequent time the menu is popped up, making that menu useless.

Here's the error message and a partial backtrace:

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "Lexical rule results" RUNNING {102C427E33}>:
Corrupt NEXT-chain in #<HASH-TABLE :TEST EQUAL :COUNT 10 {1005EC8903}>.
This is probably caused by multiple threads accessing the same hash-table without locking.

Backtrace for: #<SB-THREAD:THREAD "Lexical rule results" RUNNING {102C427E33}>
0: (SB-IMPL::SIGNAL-CORRUPT-HASH-TABLE-BUCKET #<HASH-TABLE :TEST EQUAL :COUNT 10 {1005EC8903}>)
1: (SB-IMPL::GETHASH/EQUAL #<unavailable argument> #<unavailable argument> #<unavailable argument>)
2: (CLIM:FIND-PRESENTATION-TRANSLATORS ((CLIM:MENU-ITEM) :DESCRIPTION NIL) (OR CLIM:MENU-ITEM CLIM:BLANK-AREA) #<CLIM:STANDARD-COMMAND-TABLE LIST-WINDOW {1004276C43}>)
3: ((LABELS CLIM-INTERNALS::PROCESS-PRESENTATION :IN CLIM-INTERNALS::MAP-APPLICABLE-TRANSLATORS) ((OR CLIM:MENU-ITEM CLIM:BLANK-AREA) . #<FUNCTION (LAMBDA (CLIM-INTERNALS::OBJECT TYPE CLIM:EVENT CLIM-INTERNALS::OPTIONS) :IN CLIM:MENU-CHOOSE-FROM-DRAWER) {102C7216FB}>) #<CLIM:STANDARD-PRESENTATION 0:113,0:447/32 ((CLIM:MENU-ITEM) :DESCRIPTION NIL) {102C708C03}>)

Looking at clim-core/presentation/translators.lisp, the problem seems to be that there's a single cache (a hash table) for each command table; however, the same command table can be written and read by multiple threads, and there's no attempt to make the cache thread-safe.

Possible solutions could be: (1) change the cache to be per-thread; (2) use implementation-specific hash-table extensions to make the cache synchronized and/or lock it during access; or (3) put a lock from a standard library around the cache update code.

For my application I've patched McCLIM using solution (2) - this works for me as a temporary expedient so long as I stick with SBCL. But McCLIM itself should be portable across CL implementations, so that's not the definitive solution.