The documentation is (very likely) wrong. You can’t actually avoid a copy when using multiprocessing.Queue (which torch.multiprocessing.queue inherits from). I totally get why this statement is there though because in C/C++ it is possible to avoid the copy. In this case one would NOT use a queue though.
Beginning with Python 3.8 there is the option to use multiprocessing.shared_memory and achieve something similar to what is possible in C/C++. This is a fairly new feature though, and - frankly - it is a nightmare to figure out what multiprocessing exactly does when under the hood because it is heavily OS-dependent. Hence, having that statement there is perfectly reasonable, albeit erroneous. I’d suspect that some smart person will soon submit a PR that allows using multiprocessing.shared_memory instead of multiprocessing.queue when sharing tensors if this isn’t already happening as we speak.
The way “shared process memory” works under the hood is by sharing a memory-mapped file which multiple processes can read and write to. On POSIX-based systems (Linux) there is also something called a unix domain socket. This is very similar to the familiar web-socket (same API), except that it writes to - you guessed it - a file, which typically resides in memory.
On Linux, roughly speaking, multiprocessing.Queue instantiates such a domain socket (it’s a pretty reasonable analogy) and then uses it to pass data around in the same fashion you’d pass data between two servers. This is why objects get serialized and why copies are unavoidable in this approach. When being sent, objects get placed into the queue (written to the file), and once received, they get evicted from the queue (read from the file). This is what a queue DOES; it also is the reason you don’t want to use this paradigm if you want to avoid copies.
On Windows, I am actually not sure what happens (I have not seen good documentation nor enlightening examples yet). If I had to guess, then I would say python goes down the mmap route, and handles the queue logic by itself to match the behavior to the behavior on Linux. It’s still a queue though, so it will still copy data in and out of the (memory-mapped) file.
On a tangent: Memory mapping implies host-managed, paged memory (though you might be able to turn that off) which means you’ll need an additional copy to pinned memory before sending it to the GPU for inference.