[Python-Dev] fork or exec?

[Victor Stinner]

> 2. the solution you're proposing doesn't close the file descriptors
> after fork() but after *exec()*.

Exact. My PEP cannot solve all issues :-) I will update it to make it
more explicit.

> Having an official afterfork facility would still help.

Yes. IMO it is a different topic: you can also call exec() without
calling fork() first ;-)

Victor

2013/1/10 Antoine Pitrou <solipsis at pitrou.net>:
> Le Thu, 10 Jan 2013 11:35:29 +0100,
> Charles-François Natali <neologix at free.fr> a écrit :
>> > So, I read your e-mail again and I'm wondering if you're making a
>> > logic error, or if I'm misunderstanding something:
>> >
>> > 1. first you're talking about duplicate file or socket objects after
>> > *fork()* (which is an issue I agree is quite annoying)
>> >
>> > 2. the solution you're proposing doesn't close the file descriptors
>> > after fork() but after *exec()*.
>> >
>> > Basically the solution doesn't address the problem. Many fork()
>> > calls aren't followed by an exec() call (multiprocessing comes to
>> > mind).
>>
>> Yes.
>> In this specific case, the proper solution is to close the server
>> socket right after fork() in the child process.
>>
>> We can't do anything about file descriptors inherited upon fork() (and
>> shouldn't do anything of course, except on an individual basis like
>> this socket server example).
>
> Having an official afterfork facility would still help. I currently
> rely on multiprocessing.util.register_after_fork(), even though it's an
> undocumented API (and, of course, it works only for those child
> processes launched by multiprocessing, not other fork() uses).
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com