[03:02:05] --- Simon Wilkinson has left [03:36:22] --- Simon Wilkinson has become available [05:24:51] --- lars.malinowsky has become available [05:53:24] --- meffie has become available [07:38:53] --- Simon Wilkinson has left [07:38:56] --- Simon Wilkinson has become available [07:55:44] --- Simon Wilkinson has left [08:07:44] --- deason/gmail has become available [08:18:04] --- lars.malinowsky has left [09:45:17] --- jaltman/FrogsLeap has left: Disconnected [09:49:18] --- jaltman/FrogsLeap has become available [09:51:01] --- meffie has left [09:58:31] --- Russ has become available [10:35:12] --- meffie has become available [10:45:09] --- Simon Wilkinson has become available [12:59:48] --- lama has become available [13:40:11] This looks very, very interesting : http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June/015899.html [13:40:49] Essentially, once it's done, you can annotate your structures and locks, and clang's static analyser will warn you when you access a structure element without holding the appropriate lock. [13:42:08] "Crap, I can't handle that much output" [for the FreeBSD case, which I know is really bad at the moment] [13:42:48] It will also do lock hierarchy verification too. [13:43:17] That I think we are better on, though I still have an RT ticket or two open ... [13:43:33] What's interesting is that with tools like these, getting rid of the GLOCK in Unix seems at least slightly plausible. [13:44:57] Sure. It shouldn't be too bad to do it piecewise ... "famous last words" [13:46:11] Piecewise is going to hurt, because everything is so entangled. And the current locking is completely inappropriate, because all that does is ensure we're safe when we drop the GLOCK. [15:29:58] --- deason/gmail has left [15:43:34] --- jaltman/FrogsLeap has left: Disconnected [15:48:25] --- meffie has left [23:04:29] --- Russ has left: Disconnected [23:04:40] --- jaltman/FrogsLeap has become available [23:21:32] --- lama has left