Author javen72
Recipients amaury.forgeotdarc, eckhardt, ggenellina, javen72
Date 2009-01-16.08:37:29
SpamBayes Score 0.0982303
Marked as misclassified No
Message-id <1232095057.09.0.659451785792.issue4944@psf.upfronthosting.co.za>
In-reply-to
Content
I narrowed down the root cause in the GIL of Python. I read the source
code of implementing os.fsync and found it's using
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS to enclose the calling
of _commit() in order to be thread safe. I tried to add them in my C
extension and then the issue was reproduced. 

It looks like the thread state operation or GIL caused a race condition
and let os.fsync() not flush the makefile in buffer to disk before it
returns.

The multi-thread scenario in my application is 

    a. the main thread produces makefile
    b. once a makefile is generated, the main thread launches a new
thread in which a separated process is launched to run the makefile
until it exits.

I think there's no issue in this multi-thread scenario. And the Python
2.5.2 Maunal, Python/C API Ch8.1, says GIL must be taken care when doing
some blocking I/O operations, but it caused thread unsafe. So I still
think there's a bug in the Python.
History
Date User Action Args
2009-01-16 08:37:37javen72setrecipients: + javen72, amaury.forgeotdarc, ggenellina, eckhardt
2009-01-16 08:37:37javen72setmessageid: <1232095057.09.0.659451785792.issue4944@psf.upfronthosting.co.za>
2009-01-16 08:37:32javen72linkissue4944 messages
2009-01-16 08:37:30javen72create