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
33 matches
Mail list logo
