-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python's STDOUT isn't flushed #32
Comments
One can work around this issue by adding the following to one's program: END { Inline::Python::py_finalize(); } |
That doesn't quite solve the output issue. See here; we get all the output, but it is scrambled. |
That's expected, completely normal, and not a bug in the module. |
Then it might warrant a comment in the docs. Would you take a PR for such? |
Whenever you have two things trying to use one resource (e.g. a terminal), coordination (e.g. synchronization) is required, or at least needs to be considered. |
Yes, I see now. Here, we have two interpreters running, each with its own process space. Would this be an issue if we were inlining a compiled language? I would think not because then the inline'd code is just a library being executed in the Perl process space. The distinction is important to me in terms of how I want to propose a documentation PR - I propose it would go in the Inline docs themselves under a heading like "Considering Non-Compiled Inline Modules" |
On Mittwoch, 18. August 2021 19:00:13 CEST Matthew O. Persico wrote:
Yes, I see now. Here, we have two interpreters running, each with its own
process space. Would this be an issue if we were inlining a compiled
language? I would think not because then the inline'd code is just a
library being executed in the Perl process space.
That's not correct. The Python interpreter is running the very same process as
Perl does. In fact the Python interpreter really is just a library written in
C. The same is actually true for Perl itself. You'll run into the same issue
with any library that is written like it's fully in charge of a ressource like
STDOUT.
|
"running, each with its own process space", You mean address space? There
isn't two. There's only process and thus only one address space.
"Would this be an issue if we were inlining a compiled language?" But you
are loading a library written in a compiled language. (Not sure in which
language `python` is written. C?)
…On Wed., Aug. 18, 2021, 2:00 p.m. Matthew O. Persico, < ***@***.***> wrote:
Whenever you have two things trying to use one resource (e.g. a terminal),
coordination (e.g. synchronization) is required, or at least needs to be
considered.
Yes, I see now. Here, we have two interpreters running, each with its own
process space. Would this be an issue if we were inlining a compiled
language? I would think not because then the inline'd code is just a
library being executed in the Perl process space.
The distinction is important to me in terms of how I want to propose a
documentation PR - I propose it would go in the Inline docs themselves
under a heading like "Considering Non-Compiled Inline Modules"
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFK2ZPAECCWGLA6GPYIHB3T5PRJ3ANCNFSM5BR4QU5A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
As reported on StackOverflow, Python's STDOUT isn't flushed
Output:
Who knows what other destruction doesn't occur.
The text was updated successfully, but these errors were encountered: