RetroSearch Browse

Mon Dec 22 17:41:37 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-December/041394.html

Guido van Rossum <guido at python.org> writes:

>> Unfortunately, this is redhat's position.
>> 
>> ------- Additional Comments From roland at redhat.com  2003-12-22 16:37 -------
>> I think it is clear that the specification refers to the elements of
>> the child process state that survive exec, so that the executed
>> command can perceive them as part of its "environment".  You could
>> submit an interpretation request, but I think the committee would
>> concur with my reading.  The specification of pthread_atfork refers to
>> calls to fork, not to other parts of the POSIX.1 implementation.  If
>> your application calls system, and not fork, those clauses do not
>> apply to it.
>
> How hard would it be to reimplement our own system() and popen() using
> only POSIX calls, for POSIX systems?  I've always thought of these to
> be pretty simple combinations of fork() and exec(), with an assumption
> of a working /bin/sh.  Without error checking:

I think it's a bit harder than what you post, but there's code in APUE
for it...

Cheers,
mwh

-- 
  I'd certainly be shocked to discover a consensus.  ;-)
                                             -- Aahz, comp.lang.python

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-December/041394.html below:

[Python-Dev] Python threads end up blocking signals in subprocesses