> I think the best place for it would be as a new method "set_noinherit"
> for file and socket objects or as a new function in the os module
> (thus the implementation should probably be rewritten at the C level).
Indeed. Can you come up with a C implementation of it?
I think it should be a functi
> Martin v. Löwis wrote:
> Exactly. My proposal is still to provide an API to toggle the
> flag after the handle was created.
OK, here is an API that I tested on Windows and for sockets only.
Perhaps someone can test it on Non-Windows (Linux, for example?)
I think the best place for it would be a
> # I'm not sure about netiquette here:
> # I decided to continue posting to the python-list without CCing to
> everyone.
[I assume you mean python-dev]
Discussing this issue on the list is fine. Posting code is on the
borderline, and will have no effect, i.e. no action will come out
of (at leas
Hi,
# I'm not sure about netiquette here:
# I decided to continue posting to the python-list without CCing to
everyone.
First of all, here's the prototype.
It's a prototype and I know it's far from perfect, but it works for me
(in production code) - however, I did not yet test it on Non-Windows.
On Sun, Jun 24, 2007 at 10:48:30PM +0200, "Martin v. Löwis" wrote:
> >> I don't see why it is a requirement to *open* the file in
> >> non-inheritable mode. Why is not sufficient to *modify*
> >> an open file to have its handle non-inheritable in
> >> an easy and platform-independent way?
> >
> >
>> I don't see why it is a requirement to *open* the file in
>> non-inheritable mode. Why is not sufficient to *modify*
>> an open file to have its handle non-inheritable in
>> an easy and platform-independent way?
>
> Threads. Consider that you may fork a process on one thread right
> between the
On Jun 24, 2007, at 2:19 PM, Martin v. Löwis wrote:
> I don't see why it is a requirement to *open* the file in
> non-inheritable mode. Why is not sufficient to *modify*
> an open file to have its handle non-inheritable in
> an easy and platform-independent way?
Threads. Consider that you may for
>> Putting it into the library is fine. However, we need to find
>> an implementation strategy that meets the user's needs, and
>> is still maintainable.
>>
>> Python 3 will offer a clean solution, deviating entirely from
>> stdio.
>
> Let me point out that stdio is not the problem.
> The problem
"""
My very personal opinion:
After a sleepness night, it seems to me that this is not a Python problem
(or any other programming language at all).
It looks more like an OS design problem (on MS Windows as well as
on Linux etc). In an ideal world, when a program asks the OS to start
a child process
> I think the complaint is not so much about simplicity, but correctness.
> close_fd also closes stdin/stdout/stderr, which might be undesirable
> and differs from POSIX.
>
>
> According to the docs, stdin/stdout and stderr are not closed (
> http://docs.python.org/lib/node529.html)
Hi,
I think the complaint is not so much about simplicity, but correctness.
close_fd also closes stdin/stdout/stderr, which might be undesirable
and differs from POSIX.
According to the docs, stdin/stdout and stderr are not closed (
http://docs.python.org/lib/node529.html)
Matthieu
___
> One fix is to always use subprocess.Popen and specify that
> close_fd=True, which wasn't difficult for me, but I can imagine that
> an easy way to set close-on-exec would be simpler in other cases.
I think the complaint is not so much about simplicity, but correctness.
close_fd also closes stdin
On Sat, Jun 23, 2007 at 08:39:38AM -0700, Stephen Hansen wrote:
> I just wanted to express to the group at large that these experiences aren't
> just Henning's; we spent a *tremendous* amount of time and effort debugging
> serious problems that arose from file handles getting shared to subprocesses
> As you can see, at the C level, basically "fopen" is "open" with a
> little code around it to parse flags etc. It's the same kind of hackish code.
"little code" is quite an understatement. In Microsoft's C library
(which we would have to emulate), the argument parsing of fopen is
120 lines of co
Stephen,
thank you for speaking it out loud on python-dev.
And you know better english words like "tremendous"
and "obtuse" (whatever that means:-)
that express what a PITA this really is.
When I said it took me two weeks, that's actually not the truth.
It was even more.
The first problem was wit
The kind of errors I mentioned ("permission denied" errors that
seem to occur without an obvious reason) have cost me at least
two weeks of debugging the hard way (with ProcessExplorer etc)
and caused my manager to loose his trust in Python at all...
I think it is well worth the effort to keep th
> "Martin v. Löwis" wrote:
>> Yes, I have a patch implemented in pure Python.
>>
>> I got the code on my workplace PC (now I am writing from home,
>> that's why I said I'll post the code later).
>>
>> The patch uses os.fdopen ( os.open (..., ...), ...).
>> It translates IOError into OSError then
> Yes, I have a patch implemented in pure Python.
>
> I got the code on my workplace PC (now I am writing from home,
> that's why I said I'll post the code later).
>
> The patch uses os.fdopen ( os.open (..., ...), ...).
> It translates IOError into OSError then to raise the same class
> of excep
"""
OT: Argh - my email address is visible in the posting - I am doomed!
"""
- Original Message -
> Martin v. Löwis wrote:
>
> Do you have a patch implementing that feature? I believe
> it's unimplementable in Python 2.x: open() is mapped
> to fopen(), which does not support O_NOINHERIT.
Henning von Bargen schrieb:
> I'd like to propose a new function "open_noinherit"
> or maybe even a new mode flag "n" for the builtin "open"
> (see footnote for the names).
Do you have a patch implementing that feature? I believe
it's unimplementable in Python 2.x: open() is mapped
to fopen(), whi
I'd like to propose a new function "open_noinherit"
or maybe even a new mode flag "n" for the builtin "open"
(see footnote for the names).
The new function should work exactly like the builtin "open", with one
difference:
The open file is not inherited to any child processes
(whereas files opened
21 matches
Mail list logo
