On Mon, 5 Aug 2013 14:56:06 +0200
Victor Stinner wrote:
> 2013/7/27 Nick Coghlan :
> >> Do we even need a new PEP, or should we just do it? Or can we adapt
> >> Victor's PEP 446?
> >
> > Adapting the PEP sounds good - while I agree with switching to a sane
> > default, I think the daemonisation th
On 5 August 2013 22:52, Victor Stinner wrote:
> I checked the python-daemon module: it closes all open file
> descriptors except 0, 1, 2. It has a files_preserve attribute to keep
> some FD opens. It redirects stdin, stdout and stderr to /dev/null and
> keep these file descriptors open. If python-
I checked the python-daemon module: it closes all open file
descriptors except 0, 1, 2. It has a files_preserve attribute to keep
some FD opens. It redirects stdin, stdout and stderr to /dev/null and
keep these file descriptors open. If python-daemon is used to execute
a new program, the files_pres
2013/7/27 Nick Coghlan :
>> Do we even need a new PEP, or should we just do it? Or can we adapt
>> Victor's PEP 446?
>
> Adapting the PEP sounds good - while I agree with switching to a sane
> default, I think the daemonisation thread suggests there may need to
> be a supporting API to help force F
2013/7/27 Guido van Rossum :
> P.S. perhaps more important than a PEP rewrite is a working patch to see how
> realistic this is. Could you make the alpha 1 release?
I already ran the whole Python test suite with non-inheritable file
descriptors when I developed the PEP 433: it just works. So I'm
c
P.S. perhaps more important than a PEP rewrite is a working patch to see
how realistic this is. Could you make the alpha 1 release?
On Saturday, July 27, 2013, Guido van Rossum wrote:
>
>
> On Saturday, July 27, 2013, Victor Stinner wrote:
>
>> 2013/7/27 Guido van Rossum :
>> > Do we even need a
On Saturday, July 27, 2013, Victor Stinner wrote:
> 2013/7/27 Guido van Rossum >:
> > Do we even need a new PEP, or should we just do it? Or can we adapt
> > Victor's PEP 446?
>
> I can rewrite the PEP 446 to:
>
> * make all file descriptors and handles non-inheritable
> * remove the cloexec param
2013/7/27 Guido van Rossum :
> Do we even need a new PEP, or should we just do it? Or can we adapt
> Victor's PEP 446?
I can rewrite the PEP 446 to:
* make all file descriptors and handles non-inheritable
* remove the cloexec parameter
* remove everything about non-blocking sockets (O_NONBLOCK),
On 27 July 2013 14:36, Guido van Rossum wrote:
> On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith wrote:
>>
>> On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote:
>>>
>>> On Sat, 27 Jul 2013 00:18:40 +0200
>>> Victor Stinner wrote:
>>> > 2013/7/26 Antoine Pitrou :
>>> > > On Fri, 26 Jul 201
On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith wrote:
>
> On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote:
>>
>> On Sat, 27 Jul 2013 00:18:40 +0200
>> Victor Stinner wrote:
>> > 2013/7/26 Antoine Pitrou :
>> > > On Fri, 26 Jul 2013 22:17:47 +0200
>> > >> """
>> > >> On Linux, setting th
On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote:
> On Sat, 27 Jul 2013 00:18:40 +0200
> Victor Stinner wrote:
> > 2013/7/26 Antoine Pitrou :
> > > On Fri, 26 Jul 2013 22:17:47 +0200
> > >> """
> > >> On Linux, setting the close-on-flag has a low overhead on
> > >> performances. Results of
On Sat, 27 Jul 2013 00:18:40 +0200
Victor Stinner wrote:
> 2013/7/26 Antoine Pitrou :
> > On Fri, 26 Jul 2013 22:17:47 +0200
> >> """
> >> On Linux, setting the close-on-flag has a low overhead on
> >> performances. Results of bench_cloexec.py on Linux 3.6:
> >>
> >> - close-on-flag not set: 7.8 u
2013/7/26 Antoine Pitrou :
> On Fri, 26 Jul 2013 22:17:47 +0200
>> """
>> On Linux, setting the close-on-flag has a low overhead on
>> performances. Results of bench_cloexec.py on Linux 3.6:
>>
>> - close-on-flag not set: 7.8 us
>> - O_CLOEXEC: 1% slower (7.9 us)
>> - ioctl(): 3% slower (8.0 us)
>>
On Fri, Jul 26, 2013 at 5:08 AM, Victor Stinner
wrote:
> After having written 2 PEP on the topic, I slowly agree that make all
> file descriptors non-inheritable is the best *compromise*. It solves
> most, or all, issues.
Right.
> The main drawback is the additionnal syscalls: on some platforms,
On Fri, 26 Jul 2013 22:17:47 +0200
Victor Stinner wrote:
> 2013/7/26 Antoine Pitrou :
> >> The main drawback is the additionnal syscalls: on some platforms, 2
> >> additional syscalls are need to make a file descriptor non-inheritable
> >> for each creation of file descriptor. According to my ben
2013/7/26 Antoine Pitrou :
>> The main drawback is the additionnal syscalls: on some platforms, 2
>> additional syscalls are need to make a file descriptor non-inheritable
>> for each creation of file descriptor. According to my benchmark on the
>> implementation of the PEP 433: the overhead of mak
Le Fri, 26 Jul 2013 14:08:35 +0200,
Victor Stinner a écrit :
>
> After having written 2 PEP on the topic, I slowly agree that make all
> file descriptors non-inheritable is the best *compromise*. It solves
> most, or all, issues.
Even stdin/stdout/stderr? I think inheriting them is the sane defa
2013/7/24 Guido van Rossum :
> But I'm also ready to propose that all this is such a mess that we
> *should* change the default fd/handle inheritance to False, *across
> platforms*, and damn the torpedoes -- i.e. accept breaking all
> existing 3rd party UNIX code for subprocess creation that bypass
On Wed, Jul 24, 2013 at 3:35 PM, Antoine Pitrou wrote:
> On Wed, 24 Jul 2013 15:25:50 -0700
> Guido van Rossum wrote:
>> >> To reduce the need for 3rd party subprocess creation code, we should
>> >> have better daemon creation code in the stdlib -- I wrote some damn
>> >> robust code for this pur
On 25Jul2013 00:35, Antoine Pitrou wrote:
| On Wed, 24 Jul 2013 15:25:50 -0700
| Guido van Rossum wrote:
| > >> To reduce the need for 3rd party subprocess creation code, we should
| > >> have better daemon creation code in the stdlib -- I wrote some damn
| > >> robust code for this purpose in my
On 7/24/2013 6:25 PM, Guido van Rossum wrote:
>>> To reduce the need for 3rd party subprocess creation code, we should
>>> have better daemon creation code in the stdlib -- I wrote some damn
>>> robust code for this purpose in my previous job, but it never saw the
>>> light of day.
>>
>> What do yo
On 24/07/2013 10:50pm, Victor Stinner wrote:
So would it be possible to implement the pass_fds parameter of
subprocess using spawnl() or the undocumented fields?
Not in a non-racy way.
spawnv() calls CreateProcess() with bInheritHandles=TRUE, so *all*
inheritable handles are inherited by the
On Wed, 24 Jul 2013 15:25:50 -0700
Guido van Rossum wrote:
> >> To reduce the need for 3rd party subprocess creation code, we should
> >> have better daemon creation code in the stdlib -- I wrote some damn
> >> robust code for this purpose in my previous job, but it never saw the
> >> light of day
On Wed, Jul 24, 2013 at 2:57 PM, Antoine Pitrou wrote:
> On Wed, 24 Jul 2013 10:56:05 -0700
> Guido van Rossum wrote:
>>
>> But I'm also ready to propose that all this is such a mess that we
>> *should* change the default fd/handle inheritance to False, *across
>> platforms*, and damn the torpedo
On Wed, 24 Jul 2013 10:56:05 -0700
Guido van Rossum wrote:
>
> But I'm also ready to propose that all this is such a mess that we
> *should* change the default fd/handle inheritance to False, *across
> platforms*, and damn the torpedoes -- i.e. accept breaking all
> existing 3rd party UNIX code f
2013/7/24 Richard Oudkerk :
>> Wow. Indeed you can -- I just tested this myself. How is this
>> accomplished? I guess the CRT has a backchannel to talk to itself when
>> it creates a process using spawn*?
>
> CreateProcess() takes a STARTUPINFO argument with undocumented fields
> cbReserved2, lpRes
On 24/07/2013 7:17pm, Guido van Rossum wrote:
> Does it also inherit sockets (which take up a different namespace than
> regular FDs in CRT, unlike UNIX)?
Not reliably. Processes created with CreateProcess() seems to inherit
socket handles just like normal handles on my computer, but on some
o
On Wed, Jul 24, 2013 at 11:13 AM, Richard Oudkerk wrote:
>> Wow. Indeed you can -- I just tested this myself. How is this
>> accomplished? I guess the CRT has a backchannel to talk to itself when
>> it creates a process using spawn*?
>
> CreateProcess() takes a STARTUPINFO argument with undocument
> Wow. Indeed you can -- I just tested this myself. How is this
> accomplished? I guess the CRT has a backchannel to talk to itself when
> it creates a process using spawn*?
CreateProcess() takes a STARTUPINFO argument with undocumented fields
cbReserved2, lpReserved2. They are used to pass an
On Tue, Jul 23, 2013 at 4:21 PM, Richard Oudkerk wrote:
> On 23/07/2013 11:45pm, Victor Stinner wrote:
>>
>> Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on
>> *handles*, as indicated in its name. On Windows, file*descriptors*
>> are never inherited (are always closed) in chil
On 23 July 2013 23:45, Victor Stinner wrote:
> Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on
> *handles*, as indicated in its name. On Windows, file *descriptors*
> are never inherited (are always closed) in child processes. I don't
> think that it is possible to inherit fi
The multiprocessing module is an example of use case relying on
inherance of handles. It calls CreateProcess() with
bInheritHandles=TRUE to share a pipe between the manager (parent) and
the worker (child process).
Note: subprocess and multiprocess have their own function to set the
HANDLE_FLAG_INH
On 23/07/2013 11:45pm, Victor Stinner wrote:
Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on
*handles*, as indicated in its name. On Windows, file*descriptors*
are never inherited (are always closed) in child processes. I don't
think that it is possible to inherit file descri
Hi,
Guido van Rossum and others asked me details on how file descriptors
and handles are inherited on Windows, for the PEP 446.
http://www.python.org/dev/peps/pep-0446/
I hacked Python 3.4 to add a os.get_cloexec() function (extracted from
my implementation of the PEP 433), here are some results.
34 matches
Mail list logo
