freenode/#lisp - IRC Chatlog
Search
21:18:11
jasom
it won't show you directly, but you should see threads spending a lot of time in lock acquisition
21:18:55
jasom
if you don't have a good one, just break all threads into the debugger randomly a dozen times and see what locks are contended (if contention is more than half the problem, you should see 5 or more of the same lock contended)
21:19:39
jasom
drmeister: not easy to tell from that graph; depending on the lock implementation you get very different CPU profiles for contention
21:20:03
jasom
e.g. some userspace mutexes will spin a few times before blocking, others will always do a syscall even in the non-contended case
21:20:53
jasom
shouldn't need to look at backtraces; the lock acquisition code should be on the top of the stack when waiting
21:22:07
drmeister
I mean when I use dtrace I get lots of backtraces and the lock acquisition should be at the top of the stack in many of them.
0:26:36
jasom
ACTION is secretly hoping that the issue will be the GC stopping the workd and drmeister will spend the next 6 months writing a state-of-the-art concurrent GC for clasp
1:02:31
verisimilitude
I usually make that mistake as well, didi, unless I recently made it and recall.
1:03:07
jasom
I also think that SBCL is wrong about ~{~} with nil as the argument, because the spec says "If before any iteration step the list is empty, then the iteration is terminated."
1:06:07
jasom
IMO the only conforming thing to do with (format nil "~{~}" nil) is to return "" which is not what sbcl does. Be interesting to see if this has been discussed before
3:58:37
beach
jasom: Did you look at the chapter about garbage collection in the SICL specification?
4:42:12
mfiano
Excuse me for not paying attention to the discussions here in a couple weeks, but has anyone noticed that the recent QL dist has a broken trivia system?