4 ms·
> That said, pipe() is not "portable" either, so whether to use platform-dependent code for pipes or semaphores... no big difference. pipe() is in POSIX base s
by temac 7y ago
> That said, pipe() is not "portable" either, so whether to use platform-dependent code for pipes or semaphores... no big difference.
pipe() is in POSIX base since forever. If it is not portable, I don't know what is. Oh well C is more portable than POSIX, ok; but C does not do IPC at all (actually not even processes) so that's irrelevant. SysV semaphores are in XSI, POSIX semaphore are only in base since recently, previously they were in a Semaphore option.
So yes, pipe() is absolutely more portable. Works on all BSDs, GNU/Linux, embedded Linuxes, Solaris, dead Unixes, Android, QNX, Cygwin (where on the other hand semget seems buggy: https://cygwin.com/ml/cygwin/2019-08/msg00099.html https://cygwin.com/ml/cygwin/2019-08/msg00099.html), Mac Os, etc.
- JdeBP 7y agoExcept that now, thanks to the GNU make change in 2017, there are two families of jobserver where previously there was one. There is a family that sets the pipe file descriptors to non-blocking mode, and there is a family that sets the pipe file descriptors to blocking mode. Alas, the twain do not mix. So anything that wants to interoperate has to know what family of jobserver it is interoperating with. (It has been well known in the Unix world for years that if all programs do not agree on whether a shared file descriptor is in non-blocking mode, difficulties ensue. Yes, nonblock_read() and nonblock_write() would have provided a way to solve this whilst retaining interoperability.) * https://jdebp.eu/FGA/dont-set-shared-file-descriptors-to-non-blocking-mode.html https://jdebp.eu/FGA/dont-set-shared-file-descriptors-to-non...
- ChickeNES 7y ago> Oh well C is more portable than POSIX, ok; but C does not do IPC at all (actually not even processes) so that's irrelevant. C11 adds threads and mutexes