Как я могу заставить вызов read(2) вернуть EINVAL? ⇐ Linux

[Anonymous]

Контекст
Я пишу код, который эмулирует один аспект pidfds на платформах, которые их не поддерживают (старый Linux, другой Unix).
Я делаю это а) для того, чтобы протестировать некоторый код, связанный с pidfd, на очень старых платформах и б) как личный вызов. В основном как личный вызов/для развлечения.
Я явно не пытаюсь заново реализовать всю функциональность pidfd; На самом деле меня не волнуют процессы/

Код: Выделить всё

/proc

/PID вообще. Вместо этого я пытаюсь имитировать только одну часть возможностей pidfd: тот факт, что файловый дескриптор pidfd имеет три поведения:

• При открытии в режиме блокировки , блокируется при чтении.
• Если открыто или переведено в неблокирующий режим, возвращает EWOULDBLOCK при чтении.
• Явно возвращает EINVAL< /code> при чтении.

Эта третья часть — сложная часть и необычный аспект pidfds на данный момент (еще очень мало что намеренно возвращает EINVAL< /code> for read()).
Вопрос
Я хочу вызвать такое поведение для какого-то другого типа файлового дескриптора ( не важно какой). В частности, мне нужен файловый дескриптор, который:

• По умолчанию подчиняется обычному поведению O_NONBLOCK (или нет).
• После того, как я что-то с ним сделаю, все вызовы read(2), которые обычно не возвращают ошибку, вместо этого будут возвращать EINVAL, независимо от параметров читать(2).

Это оказывается на удивление сложно.
Что я пробовал

Код: Выделить всё

read(2)На странице руководства 

для EINVAL говорится, что он возвращается, если:

fd прикреплен к объекту, который непригоден для чтения; или
файл был открыт с флагом O_DIRECT, и либо адрес,
указанный в buf, либо значение, указанное в count, либо смещение файла
не выровнено должным образом.
...или если в read(2) передан недопустимый размер буфера по таймеру.
Ни то, ни другое. случай timerfd и случай O_DIRECT удовлетворяют моим требованиям, поскольку они возвращают EINVAL только в том случае, если определенные аргументы передаются в read(2), и я хочу, чтобы он возвращался во всех не- случаи ошибок.
Я также пробовал signalfds (не смог найти случай, который возвращал EINVAL при чтении), inotify FD (то же самое) и различные варианты принудительного закрытия (2) < /code>d или Shutdown(2) каналы, FIFO и анонимные сокеты.
Однако я не очень хорошо разбираюсь в мелочах POSIX, так что это вполне возможно. Я упустил кое-что, что позволяет типу файлового дескриптора, с которым я уже экспериментировал, возвращать EINVAL.
Бонусные баллы, если есть решение, которое работает на BSD/MacOS, но на самом деле все что угодно это лучше, чем ничего, даже если это зависит от Linux или версии ядра.

Подробнее здесь: https://stackoverflow.com/questions/787 ... urn-einval