Opened 12 years ago

Closed 11 years ago

#173 closed defect (fixed)

loop form wedges event thread

Reported by: rme Owned by: gb
Priority: minor Milestone:
Component: IDE Version:
Keywords: Cc:

Description

The following forms, typed into a listener, wedge the event thread.

(in-package "CCL")
(loop for k being each hash-key of *objc-method-signatures* do (format t "~&~s" k))

If I type them at the tty where I did (require 'cocoa), it works as expected.

Change History (3)

comment:1 Changed 12 years ago by rme

Thought r7610 might fix this, but looks like not.

comment:2 Changed 12 years ago by gb

  • Status changed from new to assigned

I tried this a minute ago. I don't know if the event thread's wedged in the same ways that it usually gets wedged, but:

The event thread's trying to look up a method signature at runtime, because of the cheesy way that %CALL-NEXT-OBJC-METHOD is implemented. For obscure reasons having to do with rehashing, GETHASH thinks that it needs exclusive write access to the hash table, so the event thread's call history looks like:

(#x0000000000442CB0) #x00003000403EF984 : #<Function %NANOSLEEP #x00003000403EF75F> + 549
(#x0000000000442CF8) #x00003000400721A4 : #<Function WRITE-LOCK-RWLOCK #x000030004007208F> + 277
(#x0000000000442D28) #x000030004005343C : #<Function GETHASH #x000030004005334F> + 237
(#x0000000000442D98) #x0000300040E3852C : #<Function OBJC-METHOD-SIGNATURE-INFO #x0000300040E384DF> + 77
(#x0000000000442DB0) #x0000300040E42A3C : #<Function %CALL-NEXT-OBJC-METHOD #x0000300040E4281F> + 541
(#x0000000000442DF0) #x000030004188F38C : #<Function -[HemlockTextStorage beginEditing] #x000030004188EF9F> + 1005
(#x0000000000442E58) #x000030004012D824 : #<Function %PASCAL-FUNCTIONS% #x000030004012D68F> + 405
(#x0000000000442F18) #x000030004133B76C : #<Anonymous Function #x000030004133B69F> + 205
(#x0000000000442F38) #x0000300040E421AC : #<Function SEND-UNAMBIGUOUS-MESSAGE #x0000300040E41F9F> + 525
(#x0000000000442F80) #x000030004149FC7C : #<Function RUN-EVENT-LOOP #x000030004149FAEF> + 397

The Hemlock thread for the listener window is waiting for the event thread to acknowledge something a #/performSelectorOnMainThread: call. (Recall that the event thread is waiting for access to the objc-method-signatures hash table.)

The listener itself is trying to write to its pty. Nothing seems to be listening, and the write calls may be blocking. The writes are happening inside a MAPHASH-like iteration, which needs to do something to limit other threads' access to the table, but may not need to hold an exclusive lock (that the event thread's waiting for.)

Lest one think that there's a thread in here that's actually getting something done, the "housekeeping" thread which forces output to interactive streams is waiting for a lock on the listener's output stream.

This seems like a Perfect Deadlock Storm, and the biggest culprit seems to be caused by the fact that hash-table locking (from GETHASH and MAPHASH, especially) is too heavyweight. (Smaller culprits - like the fact that %CALL-NEXT-OBJC-METHOD does runtime lookup in hash tables - are likely to be only incidentally at fault.)

comment:3 Changed 11 years ago by gb

  • Resolution set to fixed
  • Status changed from assigned to closed

I think that I once figured out how to keep %CALL-NEXT-OBJC-METHOD from doing a runtime hash-table lookup, but never checked that in.

MAPHASH and variants only lock the table (if that makes sense) for as long as it takes it to copy the keys and values to (hopefully stack-consed) vectors; that's been true since late 2007 or early 2008.

Note: See TracTickets for help on using tickets.