Выбрать () системный вызов в потоках?
Будьте осторожны с этим вручную.
Фактически, я бы посоветовал не делать это вообще.
На самом деле речь идет о последовательности завершения строки LTS, специфичной для платформы.
Если вы откроете файл в текстовом режиме (т.е. не в двоичном), то потоки преобразуют «\ n» в правильный LTS для вашей платформы. Затем преобразуйте LTS обратно в "\ n" при чтении файла.
В результате, если вы напечатаете «\ r \ n» в файл Windows, вы получите последовательность «\ r \ r \ n» в физическом файле (посмотрите с помощью шестнадцатеричного редактора).
Конечно, это настоящая боль при передаче файлов между платформами.
Теперь, если вы пишете в сетевой поток, я бы сделал это вручную (так как большинство сетевых протоколов это специально называют). Но я хотел бы убедиться, что поток не выполняет никакой интерпретации (поэтому двоичный режим был уместен).
2 ответа
Спецификация POSIX (выберите) - это место, где можно найти определение select . Я лично рекомендую опрос - он имеет лучший интерфейс и может обрабатывать любое количество дескрипторов, а не системный лимит.
Если я правильно понимаю, вы пробуждаете потоки на основе состояния определенного дескрипторы. Лучшим способом было бы, чтобы каждый поток имел свой собственный дескриптор и сам вызывал select. Видите ли, select не изменяет состояние системы, и пока вы используете локальные переменные потока, это будет безопасно. Однако вы обязательно захотите убедиться, что не закрываете дескриптор, от которого зависит поток.
Использование select / poll с тайм-аутом оставляет "ожидание" на стороне ядра, что означает, что поток обычно переводится в спящий режим. Пока поток спит, он не использует процессорного времени. Цикл while / for в вызове select без тайм-аута, с другой стороны, даст вам более высокую загрузку ЦП, поскольку вы постоянно вращаетесь в цикле.
Надеюсь, это поможет.
EDIT : Кроме того, select / poll может иметь непредсказуемые результаты при работе с тем же дескриптором в нескольких потоках. Простая причина этого заключается в том, что первый поток может быть разбужен, потому что дескриптор готов к чтению, но второй поток должен ждать следующего "доступного для чтения" пробуждения.
Пока как и ты'
Это системный вызов - я думаю, он должен быть потокобезопасным.
Я не делал этого раньше, но был бы весьма удивлен, если бы это было не так. Насколько интенсивна загрузка процессора select () , на мой взгляд, в значительной степени зависит от количества ожидаемых файловых дескрипторов. select () в основном используется для ожидания готовности некоторого числа (> 1) дескрипторов файлов.
Также следует упомянуть, что select () не следует используется для опроса дескрипторов файлов - по соображениям производительности. Обычное использование: у вас есть работа, и может пройти некоторое время, прежде чем начнется следующее. Теперь вы приостанавливаете свой процесс с помощью select и позволяете запускать другой процесс. select () обычно приостанавливает активный процесс. Как это работает вместе с потоками, я не уверен! Я бы подумал, что весь процесс (и все потоки) приостановлены. Но это можно задокументировать. Это также может зависеть (в Linux) от того, используете ли вы системные потоки или пользовательские потоки. Ядро не знает пользовательских потоков и, следовательно, приостанавливает весь процесс.