2009/2/11 Neil Jerram <n...@ossau.uklinux.net>: > I've started working through the lock ordering and threading issues > that we have. My plan is (with 1.8.x) > > - first to address problems reported by helgrind (since I think we > should take advantage of external tools before adding debug code to > Guile internally) > > - then to run Linas's define-race program, and address the problems > that that shows up (including thread-safe define, hopefully) > > - then (or maybe as part of the previous step) to look again at > Linas's lock order debugging patch, to see if it would make sense to > apply some of that. > > Does that sound sensible; have I missed anything?
Err, sort of, yes, unless I misunderstand. Guile 1.8 makes a certain basic assumption that is splattered throughout the code; it rather intentionally re-orders the order in which one of the locks is taken. If I remember correctly, its the "in guile mode" lock. So if you just go looking for locks that are released out-of-order, you'll find lots of these. At the time, I had decided that 1) it would be a lot of work to get these in order, and the patch would likely be rejected, and 2) the reordering is essentially harmless (since its consistently done). 3) there might have even been a performance hit (I don't remember) by trying to get these into order. This made using valgrind impossible, and that's why I created the custom patch -- it made a point of ignoring this one reversed-order, while checking for badness in everything else. --linas
