Before this change, the functions generated by generate-lookup-functions, and lookup-window in particular, could end up accessing the resource id hash-table without holding the display lock: If the initial lookup-resource-id call (protected by the display lock) returned nil, a fresh id was generated and stored by calling save-id. However, the display lock was release before calling save-id.
Since most implementations don't allow concurrent modification of hash-tables without special precautions, the locking bug described above could and did lead to actual failures. In fact, it was only noticed because SBCL detected an invariant violation after a hash-table had been corrupted due to this bug (See attached screenshot).
Before this change, the functions generated by
generate-lookup-functions, andlookup-windowin particular, could end up accessing the resource id hash-table without holding the display lock: If the initiallookup-resource-idcall (protected by the display lock) returnednil, a fresh id was generated and stored by callingsave-id. However, the display lock was release before callingsave-id.Since most implementations don't allow concurrent modification of hash-tables without special precautions, the locking bug described above could and did lead to actual failures. In fact, it was only noticed because SBCL detected an invariant violation after a hash-table had been corrupted due to this bug (See attached screenshot).