Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #28639
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Subject | Re: Looking for an IPC solution |
| Date | 2012-09-06 16:33 -0400 |
| Organization | > Bestiaria Support Staff < |
| References | <50410AD6.7080003@shopzeus.com> <loom.20120831T230411-646@post.gmane.org> <k29q3g$90m$1@ger.gmane.org> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.327.1346963609.27098.python-list@python.org> (permalink) |
On Thu, 06 Sep 2012 11:23:59 +0200, Gelonida N <gelonida@gmail.com>
declaimed the following in gmane.comp.python.general:
>
> My understanding was, that it forks (or whateveri is closest to fork
> under windows) and uses sockets and pickle to communicate between the
> processes.
>
In Windows, it starts a whole new program/process image from scratch
-- which is why you MUST use the "if __name__ ==..." system, since the
subprocess to run has to import the entire module, and you DON'T want it
to execute the code the creates a subprocess recursively. Whereas a
"fork" OS would have the subprocess starting with the statement
following the creation logic.
Note that this difference mainly applies to how the processes are
themselves are created... How the library wraps shared data is possibly
different (I've never understood how a "fork" process can avoid memory
conflicts if it has write access to common virtual memory blocks).
mmap is probably the closest shared memory feature available from
Python, but managing the memory file contents is not the simplest.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Looking for an IPC solution Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-06 16:33 -0400
csiph-web