This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vxgmichel
Recipients smurfix, vxgmichel
Date 2021-09-09.10:05:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1631181925.4.0.456089899673.issue44219@roundup.psfhosted.org>
In-reply-to
Content
There are a couple of reasons why I did not make changes to the stdstream related functions. 

The first one is that a PR with many changes is less likely to get reviewed and merged than a PR with fewer changes. The second one is that it's hard for me to make sure that those functions are always called with the GIL already held. Maybe some of them never hold the GIL in the first place, and I'm not familiar enough with the code base to tell.

So in the end it will probably be up to the coredev reviewing the PR, but better start small.

> Besides, nothing prevents somebody from starting a FUSE file system and then redirecting stdout to it …

I ran some checks and `python -c 'input()' < my-fuse-mountpoint/data_in` does indeed trigger an ioctl call to the corresponding fuse file system. But how would `my-fuse-mountpoint/data_in` be the stdin for the process that itself starts the fuse filesystem? I don't see how to generate this deadlock, apart from setting up interprocess communication between the fuse process and the `my-fuse-mountpoint/data_in`-as-stdin process.
History
Date User Action Args
2021-09-09 10:05:25vxgmichelsetrecipients: + vxgmichel, smurfix
2021-09-09 10:05:25vxgmichelsetmessageid: <1631181925.4.0.456089899673.issue44219@roundup.psfhosted.org>
2021-09-09 10:05:25vxgmichellinkissue44219 messages
2021-09-09 10:05:25vxgmichelcreate