[issue815646] thread unsafe file objects cause crash

Paul Bolle added the comment: > please open a new issue and attach your patch(s) there Issue 10111 now tracks the documentation problems. -- ___ Python tracker ___ ___

[issue815646] thread unsafe file objects cause crash

Ned Deily added the comment: Paul, please open a new issue and attach your patch(s) there; it should address issues in 2.7 and 3.2 only. -- nosy: +ned.deily ___ Python tracker ___

[issue815646] thread unsafe file objects cause crash

Paul Bolle added the comment: 0) I ran into some (small) problems with the documentation added by revision 62195. It seems more efficient to reuse this issue to report these. Feel free to ask me to open another issue if that's not appreciated. 1) A small patch that addresses two problems with

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The fix can not be committed to Python 2.5 because it breaks compatibility by adding another field to the PyFileObject struct and adding two new C API functions. ___ Python tracker <[EMAIL PROTECTED]>

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > I know this is long closed, but no one on the nosy list happens to have > this fix backported to 2.5, do they? :) I think that at the time no one was sure the patch was 100% harmless. It also subtly changes the behaviour of close() when cal

[issue815646] thread unsafe file objects cause crash

Kevin Watters <[EMAIL PROTECTED]> added the comment: I know this is long closed, but no one on the nosy list happens to have this fix backported to 2.5, do they? :) If not, I'll attach one here eventually... -- nosy: +kevinwatters ___ Python tracker <

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Committed to trunk in revision 62195. Misc/NEWS entry added. I also added two new C API functions: PyFile_IncUseCount and PyFile_DecUseCount along with documentation. They should be used by any C extension code that uses PyFile_AsFile and

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Ok Greg, I wasn't sure locking/unlocking the GIL would create a memory barrier but it sounds logical after all. Your patch looks fine to me. Tracker <[EMAIL PROTECTED]>

[issue815646] thread unsafe file objects cause crash

Trent Nelson <[EMAIL PROTECTED]> added the comment: Patched and tested on one of my buildbots, test_file passes without error with your latest Patch Greg. -- nosy: +Trent.Nelson Tracker <[EMAIL PROTECTED]> __

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I've attached my patch that I want to commit. The main change from filethread4 is some cleanup in file_test to make it run a lot faster and add verbose mode output to indicate how well it is actually testing the problem (counting the times

[issue815646] thread unsafe file objects cause crash

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I'm reviewing this patch now and plan to commit it after some testing. A couple comments: I'd rename your sts variables to status. Also FYI: Your use of volatile on the int unlocked_count member of PyFileObject does not do what you think

[issue815646] thread unsafe file objects cause crash

Changes by Jeffrey Yasskin <[EMAIL PROTECTED]>: -- nosy: +jyasskin Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing list Un

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Ah, I had forgotten to protect the print statement as well. Here is a new patch :-) Added file: http://bugs.python.org/file9895/filethread4.patch Tracker <[EMAIL PROTECTED]>

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Actually, my approach was not 100% correct, it failed in some rare cases. I've come to the conclusion that using an unlock count on the PyFileObject is the correct way to proceed. I'm now attaching a working and complete patch which protects a

[issue815646] thread unsafe file objects cause crash

Georg Brandl <[EMAIL PROTECTED]> added the comment: Closed #595601 as a duplicate. -- nosy: +georg.brandl Tracker <[EMAIL PROTECTED]> __

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Some good news: I've found a way to continue with my approach and make it working. The close() method now raises an appropriate IOError when another method is being called from another thread. Attaching a patch, which protects a bunch of file

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Why hadn't I read #595601 in detail, it has an explanation: [quoting Jeremy Hylton] The universal newline code is squirrels the FILE * in a local variable, which is worse. If it happens that another thread closes the file, at best the local

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: On the other hand, surprisingly enough, the flockfile/funlockfile manpage tells me that: The stdio functions are thread-safe. This is achieved by assigning to each FILE object a lockcount and (if the lockcount is nonzer

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Another approach would be to add a dedicated lock for each PyFileObject. This sounds a bit bad performance-wise but after all the GIL itself is a lock, and we release and re-acquire it on each file operation, so why not? _

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: This is a preliminary patch which shows how things might be done better. It only addresses close(), seek() and dealloc right now. However, as mentioned in test_close_open_seek, if I raise the number of workers, I get crashes (while test_close_

[issue815646] thread unsafe file objects cause crash

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: A small addition to Christian's code snippet allows me to reproduce the problem as well: import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f = open("tmp1", "w") f.seek(0,0) thread.

[issue815646] thread unsafe file objects cause crash

Changes by Christian Heimes: -- versions: -Python 2.3 Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing list Unsubscribe:

[issue815646] thread unsafe file objects cause crash

Christian Heimes added the comment: I'm still able to reproduce the bug in Python 2.5 (svn) and 2.6 (trunk). import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek(0,0) thread.start_new_thread(worker, ()) thread.st

[issue815646] thread unsafe file objects cause crash

Sean Reifschneider added the comment: If I read the 2003 python-dev thready correctly, there isn't a solution to this. Does this need to go back to python-dev, or do we just call it "wont fix"? Or...? -- assignee: -> tim_one nosy: +jafo, tim_one T

[issue815646] thread unsafe file objects cause crash

Changes by Georg Brandl: -- priority: normal -> urgent severity: normal -> major type: -> crash Tracker <[EMAIL PROTECTED]> ___ Pyt