Неблокирующий доступ к собственным файлам - однопоточный демон в C?

Я обнаружил, что собственный доступ к файлам не имеет «неблокирующего» состояния. (Я прав?)

Я искал демонов, которые являются «неблокирующими», и я нашел один, который достиг указанного поведения путем потоковой обработки операций доступа к файлам, так что демон не блокируется.

Мой вопрос в том, не будет ли многопоточность и IPC такие операции довольно дорогими? не было бы больше смысла: A) Пул перед потоком, просто иметь каждого клиента в потоке и позволять ему блокировать любые блокирующие операции, которые ему могут понадобиться. Или,

B) В случае блокировки доступа к файлу используйте относительно небольшой буфер, таким образом, он все еще блокируется, но можно предположить, что крошечный буфер для нескольких операций будет иметь больше смысла, чем платить цену за многопоточность каждой операции и IPC?


c multithreading daemon nonblocking
person Doori Bar    schedule 10.10.2010    source источник
comment
Обычно используются библиотеки C, доступные в используемой системе. Для «неблокирующего» доступа к файлам это обычно делается с помощью select, poll, epoll и т. д. Доступные ресурсы зависят от среды выполнения системы/C.   -  person    schedule 10.10.2010
comment
Вы уверены, что это вариант для собственных файлов? (не FIFO и не сокеты). К сожалению, я не могу найти ничего связанного, если вы можете поделиться конкретной ссылкой, был бы очень признателен!   -  person Doori Bar    schedule 10.10.2010
comment
Это не вариант для обычных файлов, select/poll всегда сообщает о таких файлах как всегда доступных для чтения/всегда записываемых.   -  person nos    schedule 11.10.2010

Ответы (1)


arrow_upward
0
arrow_downward

Если вы используете многопоточность, требуются небольшие накладные расходы IPC. У вас есть одно и то же пространство памяти для всех ваших потоков, поэтому простой мьютекс или семафор может быть всем, что вам нужно. Теперь, если вы блокируете мьютекс или семафор слишком долго или слишком часто, зачем вообще использовать асинхронный ввод-вывод?

Что касается фактических вычислений, выполняемых потоками, выполняющими ввод-вывод, то большую часть времени они ждут, пока ядро ​​их разбудит, так что я бы не стал беспокоиться.

Если ваше приложение будет вращаться вокруг чтения файлов и других источников ввода-вывода, вы можете прочитать о шаблонах Reactor и программировании, управляемом событиями.

Кроме того, вы упомянули демона и обслуживание клиентов. Если услуга, которую вы предоставляете, заключается в чтении файлов, вычислительные затраты на создание нового потока для обслуживания каждого клиента минимальны, поскольку каждый отдельный поток будет занимать «долгое время» для выполнения запросов и в любом случае блокировать большую часть времени. Может быть проблема с памятью, если количество ваших клиентов исчисляется тысячами, но в остальном, я думаю, вы справитесь.

Дайте нам немного больше деталей о том, что вы хотите сделать, возможно, есть более простые способы.

person slezica    schedule 11.10.2010
comment
s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf - эта ссылка имеет контекст для моего вопроса. Я предполагаю, что запуск однопоточного HTTP-демона имел бы смысл, но если вы платите потоку за каждую операцию доступа к файлу - тогда я не вижу смысла. что мне не хватает? почему они выбрали этот путь? - person Doori Bar; 11.10.2010