В статье "Understanding Network I/O" (часть 1 ( http://www.onlamp.com/pub/a/python/2003/11/06/python_nio.html), часть 2 (http://www.onlamp.com/pub/a/python/2004/02/12/advanced_nio.html)) приводятся примеры создания сетевых программ на языке Python, включая использования мультитредовой модели и опроса состояний через select/ poll.
Материал подтолкнул меня обобщить используемые модели ввода/вывода:
Стратегии организации ввода-вывода:
-
Блокируемый I/O
- после вызова read/write происходит блокировка до завершения
операции, функция завершается только после принятия или передачи блока данных.
-
Неблокируемый I/0
- функция завершается сразу, если данные не были приняты/отправлены
возвращается код ошибки (т.е. нужно вызывать функции I/O в цикле пока не получим
положительный результат).
-
Мультиплексирование через select/poll
- опрашиваем список состояния сокетов,
перебирая состояния определяем сокеты готовые для приема/передачи.
Главный минус - затраты на перебор, особенно при большом числе неактивных
сокетов.
- select - число контролируемых сокетов ограничено лимитом FD_SETSIZE,
в некоторых случаях лимит обходится пересборкой программы, в других - пересборкой
ядра ОС.
- poll - нет лимита FD_SETSIZE, но менее эффективен из за большего размера передаваемой
в ядро структуры.
-
Генерация сигнала SIGIO
при изменении состояния сокета (ошибка, есть данные для приема,
или отправка завершена), который обрабатывает обработчик SIGIO.
В классическом виде применение ограничено и трудоемко, подходит больше для UDP.
-
Асинхронный I/O
- описан в POSIX 1003.1b (aio_open, aio_write, aio_read...),
функция aio_* завершается мгновенно, далее процесс сигнализируется о
полном завершении операции ввода/вывода (в предыдущих пунктах процесс информировался
о готовности прочитать или передать данные, т.е. данные еще нужно было принять или отправить
через read/write, в aio_* процесс сигнализируется когда данные полностью получены и скопированы в локальный буфер).- Передача данных об изменении состояния сокета через генерацию событий. (специфичные
для определенных ОС решения, малопереносимы, но эффективны).
-
kqueue
- лучшее для FreeBSD, NetBSD. Данные о нескольких событиях могут быть переданы за раз, очень гибкое решение.
-
/dev/epoll
- лучшее для 2.6 Linux ядра, передача нескольких событий за раз, трудоемкость поддержки /dev/epoll если параллельно в программе поддерживаются другие механизмы нотификации.
-
Realtime Signals (F_SETSIG)
- лучшее для 2.4 Linux ядра.
-
/dev/poll
- имеет смысл в Solaris, в Linux реализация недостаточно хороша.- Ссылки:
- libevent (http://monkey.org/~provos/libevent/) - очень хорошая библиотека враппер для работы с kqueue, select, poll, epoll и real-time signals.
- Краткое введение в kqueue/kevent (http://www.zlug.pp.ru/book/view/164) (rus);
- kqueue - a generic and scalable event notification facility (http://people.freebsd.org/~jlemon/papers/kqueue.pdf)
- man kqueue (http://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2&ma...
LEASE)
- Слайды "The kqueue facility in FreeBSD (http://www.madison-gurkha.com/publications/kqueue/kqueue.htm)"
- /dev/epoll - a highspeed Linux kernel patch (http://epoll.hackerdojo.com/)
- Improving (network) I/O performance (http://www.xmailserver.org/linux-patches/nio-improve.html) - описание /dev/epoll с примерами кода, неплохое сравнение с poll(), realtime signals и /dev/poll.
- signal-per-fd" Linux kernel patch (http://www.luban.org/GPL/gpl.html)
- Analysis of RealTime Signals for Highly Concurrent Network I/O (http://squid.visolve.com/developments/squid_rt_whitepaper.htm)
- Using the devpoll (/dev/poll) Interface (http://access1.sun.com/techarticles/devpoll.html)
Using the select() and poll() methods (http://builder.com.com/5100-6372-1044098.html)URL: http://www.onlamp.com/pub/a/python/2004/02/12/advanced_nio.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=3408
/dev/epoll нету, есть просто epoll :)