[Python-bugs-list] [ python-Feature Requests-468153 ] os.fork() in win32 port

[SourceForge.net]

Feature Requests item #468153, was opened at 2001-10-04 23:15
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.fork() in win32 port

Initial Comment:
The only thing that would make the windows version of python fully functional (in my opinion), is os.fork().

I don't know where the real issue lies in this, whether it's a win32 api problem or not.

I would use the cygwin port of python, which has support for os.fork(), except that it has broken thread support (an issue with cygwin's posix threads).




As a side note, cygwin's python has much faster console IO...roughly on the order of 10x or more.  Strange feature...

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-05-12 22:35

Message:
Logged In: YES 
user_id=31435

Yes, feel free to close it.  Implementing fork() on Windows 
requires heroic effort, and the result isn't pretty.  BTW, 
note that fork() isn't defined by the C standard -- it's very 
much an OS gimmick.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 22:03

Message:
Logged In: YES 
user_id=357491

I have heard it stated enough times that os.fork is not available on Windows 
since it just does not provide it that I think this should be closed.  Any 
objections?

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2001-10-16 10:04

Message:
Logged In: YES 
user_id=341410

I actually hadn't noticed the spawn* operations in the OS 
module.

I can see how passing arguments to a command line could be 
a bit cumbersome, especially when the fork or spawn was 
supposed to be in deep control flow.

I'm sure that I could get it to work for most anything I 
would need it to do, but like how fork is implemented in 
cygwin, os.spawn* seems to be quite hacky, or at least 
one's code using it and recovering from it could be.

Part of the reason I didn't know about the spawn functions 
is that while having used fork in c (in *nix and cygwin), 
neither c/c++ courses nor operating systems courses teach 
about spawn (I don't know much about c/c++, and do not know 
if it is a python specific operator or if it is available 
in other languages), but they do teach about fork.

As a user of the language, if I need a feature that I've 
used in another language, I look for something with a 
similar name to what I've already used.  To get people to 
learn about spwan, referring to it in the fork section of 
the documentation as an alternative to fork on win32 and 
*nix would possibly make it wider known.

Thank you for the information,
 - Josiah

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-16 04:04

Message:
Logged In: YES 
user_id=21627

I believe fork is unimplementable correctly with the Win32
API. There is simply no API call for "create a process that
shares address space with the original process in a
copy-on-write fashion".

Instead, cygwin creates a new process, and then copies the
complete address space from one process to the other. This
looks quite hacky, and I think Python users should accept
that fork is system specific, and use os.spawn* instead.

Can you please explain why you need fork, and why spawnv is
not sufficient?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470