[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.
Change by Jason Wilkes : -- nosy: +notarealdeveloper nosy_count: 7.0 -> 8.0 pull_requests: +29528 pull_request: https://github.com/python/cpython/pull/30310 ___ Python tracker <https://bugs.python.org/issue46541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46679] test.support.wait_process ignores timeout argument
Change by Jason Wilkes : -- keywords: +patch pull_requests: +29375 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31205 ___ Python tracker <https://bugs.python.org/issue46679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46679] test.support.wait_process ignores timeout argument
New submission from Jason Wilkes : The function wait_process in Lib/test/support/__init__.py ignores its timeout argument. This argument is useful, for example, in tests that need to determine whether a deadlock has been fixed (e.g., in PR-30310). Will submit a pull request to fix this. -- components: Tests messages: 412793 nosy: notarealdeveloper priority: normal severity: normal status: open title: test.support.wait_process ignores timeout argument type: behavior versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46678] Invalid cross device link in Lib/test/support/import_helper.py
Change by Jason Wilkes : -- keywords: +patch pull_requests: +29374 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31204 ___ Python tracker <https://bugs.python.org/issue46678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46678] Invalid cross device link in Lib/test/support/import_helper.py
New submission from Jason Wilkes : In Lib/test/support/import_helper.py, the function make_legacy_pyc makes a call to os.rename which can fail when the source and target live on different devices. This happens (for example) when PYTHONPYCACHEPREFIX is set to a directory on a different device from where temporary files are stored. Replacing os.rename with shutil.move fixes it. Will submit a PR. -- components: Tests messages: 412791 nosy: notarealdeveloper priority: normal severity: normal status: open title: Invalid cross device link in Lib/test/support/import_helper.py type: behavior versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46210] print deadlocks
Change by Jason Wilkes : -- keywords: +patch pull_requests: +28524 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30310 ___ Python tracker <https://bugs.python.org/issue46210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46210] print deadlocks
New submission from Jason Wilkes : Hi there. :) (First time posting here, so apologies in advance if I'm a goof.) I recently found a deadlock in the stdout and stderr buffer objects. Following the dev guide, I (1) wrote up a patch (2) checked that it fixes the deadlock (on Linux and OS X) (3) made sure it doesn't break any of the cpython tests (on Linux and OS X) But I could use some feedback to make sure the patch isn't doing anything dumb, and to make sure I'm not missing something obvious. Here's the situation. The deadlock only occurs in the sinful state of threading while forking. (I'm aware of the reasons why one should never do that.) But asking newcomers to never mix the two is sort of asking them to know the implementation details of every library they use (these abstractions are leaky). And I like teaching people about python and concurrency, so it would be nice if they didn't have to know all that. So I've recently developed the ill-advised hobby of trying to run as much code as possible in the sinful state of threading while forking, to try to understand which bits of the interpreter and standard library are responsible for most of the deadlocks, in practice. All the non-obvious deadlocks I've encountered seemed to be due to one thing, namely stdout and stderr's buffer->lock not having an _at_fork_reinit. So if a thread is printing during a fork, the child process can never print, else deadlock. Standard hazard of threading and forking. What surprised me was that there didn't seem to be 100s of places in the interpreter where threading and forking don't mix. After fixing this one, all the different thread + fork code I'd been testing worked. Which makes me wonder if there's a reason this hasn't been fixed yet. Hence, maybe the patch is doing something dumb. Anyways, this is sort of a bug report, and sort of a request for comments on how I can make this patch better. Equally cool would be an explanation of why re-initializing that lock is a bad idea to begin with. Thanks for your patience if you read all that. -- components: IO files: example.py messages: 409394 nosy: notarealdeveloper priority: normal severity: normal status: open title: print deadlocks type: behavior versions: Python 3.10, Python 3.11, Python 3.9 Added file: https://bugs.python.org/file50532/example.py ___ Python tracker <https://bugs.python.org/issue46210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
