> You linked the man pages of sys5 shared memories. Everyone switched to posix shared memories since literally 20 years.

Which is irrelevant, because there is barely any functional difference between the two. POSIX SHM uses a better API, providing a file-descriptor like object. That's all.

And yes, using that API also requires syscalls.

> Furthermore, these man pages dont even support your argument.

Wrong, they absolutely do. "Accessing" something doesn't just involve the IO, it also involves the setup. And this requires syscalls, in SysV as it does in POSIX.

> Did you actually read them? These are just for the mapping, not for actually accessing (read/write) the shared memory

I am well aware of that, hence my seperate mentioning of IO later in my post. ;-)

And the argument in that post stands as solid as it was before. `mmap` MAPS memory. This mapping requires an address translation overhead EVERYTIME THE MEMORY IS ACCESSED. This translation doesn't happen in userspace.

Now, there is a way around that, in principle: If I mmap with ANONYMOUS and SHARED, and then `fork()`, I could have the same mapping in the child process. The problem here is: This relies on the forking after the mmap(). Any newly created objects, if I manage to map them into the child process, will again require address mapping. Again, this isn't an issue in threads. As soon as I create a new object on the heap, it is available to every thread, under the same address.

But hey, what do I know. But I think the people who are going to dedicate countless hours of their lives making actual parallel processing via multithreading possible in Python know why they are doing so. As do the people who implemented abstractions around threading in basically every major programming language ;-)

> Which is irrelevant, because there is barely any functional difference between the two

Well it is relevant, it tells that you're not familiar with the subject and most likely googled what looked related and found outdated man pages which seemed related.

> Wrong, they absolutely do. "Accessing" something doesn't just involve the IO, it also involves the setup

I think common sense would disagree, but if that's your line of arguing, sure.

> And the argument in that post stands as solid as it was before. `mmap` MAPS memory. This mapping requires an address translation overhead EVERYTIME THE MEMORY IS ACCESSED. This translation doesn't happen in userspace.

How deep are you willing to dig your hole there?

Two messages ago you were arguing that accessing a shared memory required syscall and thus was slow. Now you've accepted it doesn't require syscall but argue it requires some magical dynamic translation by the kernel?

I'm sorry but again that is just wrong. All the kernel does is inject the mappings when setting up TLB/MMU at context switch.

The virtual address translation happens without kernel intervention, through the MMU, in _exactly_ the same manner whether this is a named or anonymous memory mapping, whether it is a shared or heap page. In fact the MMU couldn't care less what these addresses are, it has no concept of the meaning of what it translates.

> it tells that you're not familiar with the subject and most likely googled what looked related and found outdated man pages which seemed related.

That is an assumption, for which I have yet to see proof :-)

> I think common sense would disagree

Please, do enlighten me: How do I access SHM without mapping it first, or otherwise setting it up?

> Now you've accepted it doesn't require syscall

There was nothing to accept. If you actually read my post, you will see that I talked about the issues of IO and setup seperately.

And my point stands still solid ;-) SHM requires syscalls not required when directly using shared memory.