[issue1720705] thread + import => crashes?

Changes by Forest Wilkinson : -- nosy: +forest ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue1720705] thread + import => crashes?

Adam Olsen <[EMAIL PROTECTED]> added the comment: The patch for issue 1856 should fix the potential crash, so we could eliminate that scary blurb from the docs. -- nosy: +Rhamphoryncus _ Tracker <[EMAIL PROTECTED]>

[issue1720705] thread + import => crashes?

Georg Brandl <[EMAIL PROTECTED]> added the comment: Added your remarks to threading docs in r61365. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> ___

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: (oh, one thing - the 'crashes' mentioned in my proposed wording are due to explicit calls to PyErr_FatalError rather than a segfault or anything like that. The one specifically reported by the OP is due to sys.modules being gone by the time an import is attempted)

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: Proposed wording for a warning pointing that threads and imports can get you in trouble. It might be better to squirrel off into a new subsection on threaded imports, rather than giving it too much prominence (since the recommended approach to creating subthreads s

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: And one other restriction: the thread performing the import must not be spawned as a side effect of importing a module (as this will deadlock the interpreter) The effect of disobeying the two restrictions in my previous comment will be intermittent crashes at shut

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: Correction to previous comment: you can't safely perform imports from daemon threads at all, as you have to set their daemon status before you start them. So, to be able to safely import from a thread other than the main thread: - it must be created by the threadi

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: Ahah, found the real restrictions - while it turns out the OP's demonstration code is indeed broken, I think the warning Georg added to the docs based on Christian's comment above is *far* too strong (hence my somewhat annoyed message on the checkins list ;). The

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: Ah, never mind - just needed to run the test a few more times to get it to fail. _ Tracker <[EMAIL PROTECTED]> _ _

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: Nope, can't reproduce it with the original tkinter/urllib script either (again, Ubuntu's 2.5.1 release and SVN 2.6, with the thread count set at 350). Could it be a windows specific problem? Or require a non-hyperthreaded CPU?

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: Hmm, I can't reproduce any failure using the supplied zip file, even if I increase the number of threads to 382 (if I set it any higher, start_new_thread starts to fail). That's with both 2.5.1 and 2.6 SVN. I'll try again with the original tkinter/urllib script.

[issue1720705] thread + import => crashes?

Nick Coghlan added the comment: Reopening - I disagree with the assertion that this isn't expected to work. -- nosy: +ncoghlan resolution: fixed -> status: closed -> open _ Tracker <[EMAIL PROTECTED]> ___

[issue1720705] thread + import => crashes?

Georg Brandl added the comment: Documented in both thread and threading docs in r61029. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> ___

[issue1720705] thread + import => crashes?

Christian Heimes added the comment: Follow up: Can somebody please document the possible issue with threads and imports in large, friendly letters? -- components: +Documentation -None _ Tracker <[EMAIL PROTECTED]>

[issue1720705] thread + import => crashes?

Christian Heimes added the comment: For 2.6 I've fixed several places where C code was importing a Python module in a non-threadsafe way. In general a thread start must never be caused by an import and only the main thread should import modules. Imports within or caused-by a thread other than the