> .> Thanks for your answer. But the interesting question now is : have you an
> .> exhaustive list of blocking ops?
> .
> .An exhaustive list, no. But every would-be race hunter needs to build a
> .list of known blocking operations, even if it blocks only under unusual
> .circumstances. Then when you're reviewing code and you see a potential
> .block, you can look to see what operations might be affected.
> .
> .And when you discover a new blocking operation (or one that you hadn't
> .realized could block), you should go back and re-review all the code in
> .light of the new information.
>
> == recipe for disaster.
>
> I looked for the smileys, but I couldn't find them... Seriously though, this
> is the way_to_write_bad_code. A list of blocking ops that gets updated
> centrally would be a great help for kernel code writers, no ? If every Joe
> Soap needs to maintain his own then it won't happen...
> I'd guess the scenario where someone uses an op that they hadn't realised could
> block would account for quite a good fraction of this type of
> error...
There's a bigger error. Imagine me redesigning some code. Aha - but
how can I know if someone depends on this code not blocking?
It may be nice idea to add /* Must not block */ comment to every
function that may not block... Anyone who has more knowledge than me
volunteering?
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).