[Chicago] help with file locking

[Massimo Di Pierro]

I run tests based on your suggestion and it fixed the problem completely in my stress tests.

That piece of code was a simplified version of code used to test internationalization in web2py. We never experienced problems with internationalization because the translation files are very rarely overwritten and the race condition never happens. Yet the stress test was failing because it assumed the files were overwritten by many concurrent requests.

I have patched web2py using your suggestion and your contribution has been acknowledged in the commit:
https://github.com/mdipierro/web2py/commit/02e7f38da7995e711698bf0fb2294d4243a96a73
(In the same patch I also re-factored some other pieces of web2py).

Thanks again for your help.

Massimo


On Mar 2, 2012, at 10:32 PM, Dan McGee wrote:

> On Fri, Mar 2, 2012 at 10:12 PM, Martin Maney <maney at two14.net> wrote:
>> On Wed, Feb 29, 2012 at 12:43:56PM -0600, Massimo Di Pierro wrote:
>>> Thank you! This helps a lot.
>> 
>> I think there's another problem with a race in the code.  Unlocking
>> before closing means that, at least in theory, the reader could open,
>> lock, and read the file between the writer's unlock and close, at which
>> time the new content hasn't been flushed from the buffers into the OS
>> (I was going to say "to disk", but unless you explicitly sync this sort
>> of constantly-changing test file may never get to disk at all).
> 
> The call to `fp.flush()` that I noted in my first email should have
> taken care of this completely; are you seeing otherwise?
> 
> -Dan
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20120302/5405e26a/attachment.html>