Средства и методы разработки

Пора записываться в Unix haters. Как открыть pipe (named fifo) в неблокирующем режиме, в вашем posix (Linux вычёркиваем)? Почему для файлов (select, poll), процессов (waitpid), примитивов синхронизации (sem_wait, pthread_cond_wait...), sysv IPC (msgrcv, semop), сигналов (sigwait) нужны разные и несовместимые функции ожидания? Зачем, наконец, при наличии двух видов семафоров в линуксе каждый раз проходится делать свой третий на condvar'е. Kак читать из pipe, или named fifo, блоками большого размера, если туда пишут по байтику? Как в bash узнать свой PGID? Да оно бесконечно продолжать можно. Для unix-сокетов есть SO_PEERCRED и SCM_CREDENTIALS, *два* механизма для этого предназначенных, но ни один не позволяет в итоге узнать PID процесса с другого конца. Ну или почему есть функции wait, wait3, wait4, waitpid -- с первого раза нормально тоже никак не выходило. По всем манам размазаны оговорочки, пока не прочитаешь не узнаешь, что мол в таких-то и таких-то случаях, неожиданно, вот такие-то исключения. Пример: половина syscall'ов рестартует, половина нет. На обычный sleep нихера нельзя положиться. vmsplice работает в одну сторону, а в другую никто не работает -- нужен файл. Где логика? Больше похоже на набор аккуратно расставленных костылей. Интересно кстати, память съеденная пайпами -- она же не учитывается ни в каких лимитах (ибо пайпом владеет непонятно кто, он может быть открыт в 10 разных процессах)? А то 1024 пайпа по мегабайту -- неплохо выйдет. ptrace, где на PTRACE_SINGLESTEP болт забили на ARM, мол сношайтесь в юзерспейсе, эмулируйте инструкции. А на x86 всё работает. shm_open оперирующий как будто какой-то особенной памятью, которую нужно получать отдельно от любой другой, получаемой через mmap, в итоге отдать какую-то память в соседний процесс превращается в поездку "в Крым через Рим". Нихрена не работающий umask, если автор программы в open вместо 0666 написал что-то другое. Конец файла (read вернул 0) не отличимый от пакета нулевой длины в UDP (нужен msgrecv обязательно -- вот и "всё есть файл", кроме сокета). Два способа повесить signal handler, в итоге если хочется перекрыть signal(), то нужно то же самое делать и с sigaction(), и всё достаточно неудобно. Вообще многие вещи часто делаются двумя несовместимыми способами. Сигналы не несущие в обработчик никакой ассоциированной информации (кроме realtime сигналов в linux, ну хоть тот же this передать) -- очень "удобно". Да бесконечно продолжать можно. На работу пора идти. Буду теперь в блокнотик записывать. Издам "Unix haters guide в редакции им. меня".