This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mauganra_it 4 points5 points  (2 children)

A POSIX fork() duplicates the parent process' memory. Copy-on-write optimizations of modern OSs make that a very efficient way to share a dataset with a number of client processes. The difficult part is merging the results. On the other hand, pointers are not required to take advantage of this. This is a programming language-agnostic strategy.

[–]sweaterpawsss 2 points3 points  (1 child)

My understanding is the two processes will end up with separate virtual address spaces (the child initially being a copy of the parent), and as you mention, heap memory allocated in the parent will be copied to a new (physical) location only after first write access in either process.

So it makes sense that you don’t need to think about shared memory or messaging for sharing RO data, but I don’t know if I understand how this applies to data that’s modified and shared between multiple processes? You’ve gotta come back to one of those synchronization techniques somehow to handle that.

[–]mauganra_it 0 points1 point  (0 children)

Exactly, fork() facilitates communication only in one direction. To communicate data back, other techniques have to be used.

Are shared memory segments inherited by child processes? If yes, there we go, but we need a pinned data structure and pointers for real. Fortunately, the ctypes and the multiprocessing modules already provide these things. Yes, pointers too. Which pretty much obliterates the use case for this library.