В статье "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&manpath=FreeBSD+5.2-RE
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
Новость: https://www.opennet.ru/opennews/art.shtml?num=3408