4 ms·

Pipes are FIFO data buffers implemented in the kernel. For communication between threads of the same process, you can replace any pipe object by a userspace que

Pipes are FIFO data buffers implemented in the kernel. For communication between threads of the same process, you can replace any pipe object by a userspace queue implementation protected by e.g. mutex + condition variable. It is functionally equivalent and has potential to be faster. And if you wrap all accesses in lock/unlock pairs (without locking any other objects in between) there is no danger of introducing any more deadlocks compared to using kernel pipes. Threads are an important structuring mechanism: You can assume that all your threads continue to run, or in the event of a crash, all your threads die. Also, unidirectional pipes aren't exactly sufficient for inter-process / inter-thread synchronisation. They are ok for simple batch processing, but that's about it.

gpderetta 3y ago
Incidentally you can use the exact same setup (plush mmap) for interprocess queues. The advantage of threads is that you can pass pointers to your data through the queue, while that's harder to do between processes and you have to resort to copying data in the queue instead.
- another2another 3y ago
  >while that's harder to do between processes and you have to resort to copying data in the queue instead. I could be wrong - I've never done it, but I understood that you can even store POSIX mutexes and condition vars in shared mem so that 2 processes (or more?) can process data without copying, so long as they use the both use the same locks stored in the shared memory.
  - gpderetta 3y ago
    Yes, when the mutex or condvar is inited with attribute PTHREAD_PROCESS_SHARED.
packetlost 3y ago
There are domain sockets if you need something more such as passing file descriptors. Both pipes and sockets (including TCP, with obvious limitations) can be done with zero copy given the right set of flags, thought things get harder if you have a complicated runtime (ie. garbage collection) involved. There's always explicitly mapped shared pages
- deleted 3y ago
  [deleted]

gpderetta 3y ago

Incidentally you can use the exact same setup (plush mmap) for interprocess queues. The advantage of threads is that you can pass pointers to your data through the queue, while that's harder to do between processes and you have to resort to copying data in the queue instead.

another2another 3y ago
>while that's harder to do between processes and you have to resort to copying data in the queue instead. I could be wrong - I've never done it, but I understood that you can even store POSIX mutexes and condition vars in shared mem so that 2 processes (or more?) can process data without copying, so long as they use the both use the same locks stored in the shared memory.
- gpderetta 3y ago
  Yes, when the mutex or condvar is inited with attribute PTHREAD_PROCESS_SHARED.

packetlost 3y ago

There are domain sockets if you need something more such as passing file descriptors. Both pipes and sockets (including TCP, with obvious limitations) can be done with zero copy given the right set of flags, thought things get harder if you have a complicated runtime (ie. garbage collection) involved. There's always explicitly mapped shared pages

deleted 3y ago
[deleted]