Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
It might be desirable to have an init option to enable or disable the BKL. It could make testing easier and faster.
Might 2.6.35 be BKL-free?
Posted May 1, 2010 1:42 UTC (Sat) by chantecode (subscriber, #54535)
Because it might protect datas from concurrent accesses.
>> That only invites developers to periodically introduce new dependencies. >> You will eliminate in one release only to have to put it back in later
Not really. Most of the time, a new driver that uses the bkl will be spotted
and won't be merged, except may be for the llseek case, which is a bit particular.
>> It might be desirable to have an init option to enable or disable the BKL. It could make testing easier and faster.
The problem is not here. You don't catch every possible races by just testing without the bkl. When you kill the bkl at some places, you need to prove that what you are doing is safe, by explaining the locking involved and so. Testing is not sufficient.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds