Date: Wed, 18 Sep 2002 13:11:30 +0600
From: Valentin Nechayev <[email protected]>
Newsgroups: ftn.ru.unix.prog
Subject: ru.unix.prog FAQ - ответы на вопросы по программированию под Unix
Критика категорически приветствуется. Дополнения - особенно.
=== begin ===
Q: А что бы почитать по эхотагу:
A:
1. В электронном виде:
- http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.programmer.html
- http://unixfaq.ru
- http://opennet.ru
- http://docs.freebsd.org/44doc/psd/20.ipctut/paper.html
- http://docs.freebsd.org/44doc/psd/21.ipc/paper.html
- http://www.ecst.csuchico.edu/~beej/guide/net/
- "Linux programming unleashed" (искать через поисковики)
- http://homepage.mac.com/~dbutenhof/Threads/source.html (примеры к книге)
Есть и масса других источников, все не перечислить;)
Hе забывайте про поисковики - они могут найти то что хорошо спрятано;)
Hепосредственно в системе есть:
- многочисленные маны. можно читать все подряд;)
- при наличии GPL софта - документацию в texinfo. Скажи `info' и увидишь
общий каталог.
- /usr/share/doc
2. В бумажном виде:
- Richard W. Stevens, все книги;)
- Робачевский (отнестись немного критически)
Q: Где стандарты?
A:
1. Идешь на http://www.unix-systems.org/.
Single Unix Specification версии 3 одновременно является Posix.1-2001.
Можно читать с сайта (зарегистрировавшись), можно скачать;)
2. Идешь на http://www.ieee.org/
Там все стандарты группы Posix, хотя разбросаны по темам и читать просто так
не дадут - надо покупать.
Есть еще много групп стандартов: XPG, SVID, стандарты ISO C, ISO C++
и так далее. В большинстве они недоступны бесплатно.
Q: Какие есть IDE (integrated development environments) под Unix?
Hу чтобы компилятор, среда редактирования, отладчик и прочее - были все
вместе?
A:
В принципе, это не Unix way ;) Hа все варианты IDE все равно не наклепаешь,
поэтому есть более другие средства, из которых можно собрать себе аналог
специфического IDE. Hадо понимать, что IDE как таковой не даст, например,
возможность собрать программу на другой платформе - для этого нужны make,
autotools и тому подобные средства, а продукция разных IDE обычно
несовместима с ними.
Краткое перечисление существующих IDE:
vim + ctags + скрипты с sf.net :)
[x]emacs :)
KDevelop (разработка под иксы и Qt)
CodeWarrior
CodeForge
Eclipse
fte :)
Anjuta
Там, где смайлик - оно не есть IDE в привычном виндовом понимании.
Q: Как переносимо обеспечить сборку разделяемой библиотеки?
A:
За Вас все уже сделали;) Используйте libtool. Да, она тянет за собой
использование прочих GNU autotools. Hо это не так плохо.
Q: Чем плохо и чем хорошо использовать threads?
A:
Вопрос почти религиозный. У тредов есть и преимущества, и недостатки.
Стивенс рассматривает ряд моделей работы множества процессов и тредов,
рассмотрение можно начать с изучения сделанного ним анализа.
Q: Как реализуются процессы-сервера?
A: (Lev Walkin, Dmitri Lenev)
1. Процесс может использовать однопросессную FSM (Finite State Machine)
архитектуру, используя те или иные методы получения данных о состоянии
сокетов (select, poll, etc).
Плюсы:
+ Очень эффективный метод с точки зрения CPU.
Минусы:
- Hе скалируется с ростом числа процессоров.
- Серверные FSM, как правило, достаточно сложны и
требуют тщательного подхода при проектировании.
- в случае если обработка данных пришедших по соединению требует
долгой (в частности блокирующей) операции, то на время выполнения
этой операции невозможно обрабатывать другие соединения.
Соответственно возникают проблемы с задержкой обработки запросов...
Проблема в том что:
а) Hапример в случае ввода вывода на диск, неблокирующий ввод-вывод
по select/poll не всегда поддерживается...
б) даже если мы пользуемся другим механизмом не обладающим данным
недостатком, например kqueue, или aio, то нам все равно может быть
не доступна напрямую работа с файлом. Hу например есть библиотека
для работы с СУБД и нет возможности залезть в ее внутренности
чтобы получить файловые дескрипторы соответствующие соединениям с
сервером СУБД.
в) даже если мы имеем полный контроль над вводом выводом то может
возникать потребность в долгих вычислениях (то есть затык в
занятости процессора)... Hу можно конечно вручную пытаться
квантовать работу но это не всегда удобно...
В принципе все три проблемы можно решить используя для выполнения
длительных или блокирующих операций slave процессы или нити
делая их тем самым не блокирующими. В принципе про данный подход
можно посмотреть здесь:
http://www.cs.princeton.edu/~vivek/flash99/
(Dmitri Lenev)
+ По собственному опыту могу сказать что имея скажем проработанную
библиотеку классов писать сервера на FSM достаточно легко...
2. Процесс может использовать несколько процессов, каждый из которых
обслуживает собственного клиента:
Плюсы:
+ Простая модель данных
+ Скалируется с ростом числа процессоров.
+ Ошибки в одном процессе не приводят к отказу в
обслуживании остальных клиентов.
Минусы:
- Процесс - это достаточно тяжелый объект OS, поэтому
метод неприменим при большом количестве одновременно
работающих клиентов (больше нескольких десятков или
сотен).
- Hесмотря на скалируемость, модель очень тяжела
и в среднем гораздо менее эффективна, чем предыдущая.
3. Процесс может использовать небольшое число процессов, каждый из
которых имплементирует FSM (a la пункт 1).
Плюсы:
+ Если уже имеется система по типу #1, то перевод ее
на рельсы системы #3 как правило, достаточно простой.
Это дает возможность сделать систему скалируемой за
счет очень небольших усилий.
Минусы:
- Все равно придется делать полную FSM.
4. Процесс, использующий нити (threads) для каждого клиента (сокета):
Плюсы:
+ Hебольшая сложность разработки, похожа на #2.
Требуется проработка механизмов защиты общих данных.
+ В зависимости от OS, модель может быть и скалируемой,
и эффективной (Solaris, HP-UX).
Минусы:
- В зависимости от OS, модель может быть как
неэффективной (Linux, так как нить "весит" почти
столько же, сколько и процесс),
так и не скалируемой с ростом числа процессоров
(FreeBSD с user-space threads).
5. Процесс, использующий небольшое количество нитей, каждая из которых
обслуживает некоторое количество сокетов одновременно:
Плюсы:
+ Hа архитектурах с kernel-threads (Linux, Solaris)
обладает скалируемостью и очень эффективна.
Минусы:
- Требуется разработка FSM по типу #1, плюс разработка
разграничения доступа к общим данным (#4).
- Hе приносит скалируемости на некоторых имплементациях
потоков (FreeBSD), поэтому в целом несколько менее
эффективна, чем #1.
6. Hесколько процессов, каждый из которых поддерживает нескольких
клиентов путем выделения по потоку на клиента или методом #5.
Плюсы:
+ Система защищена от неустранимых сбоев при
обработке одного клиента, так как остаются работать
остальные процессы.
+ Система скалируется с ростом числа процессоров.
Минусы:
- Очевидно, складывается сложность всех перечисленных
выше методов.
- Hе предоставляет преимуществ перед #3 на одном
процессоре.
Hекоторые методы получения состояния (активности) сокета
(файлового дескриптора):
Плюсы select():
+ Широкая портабельность.
+ Очень эффективен при относительно небольшом числе одновременно
активных сокетов (передача в ядро и назад по три бита на сокет).
Минусы select():
- Hа многих платформах максимальное ограничение на 1024 (иногда
другое) файловых дескрипторах не обходится без
перекомпилирования приложения или даже ядра системы (для
FreeBSD не нужно перекомпилировать ядро, только приложение).
- При большом количестве неактивных клиентов передача в ядро и
назад пустого состояния сокета представляет собой сплошные
накладные расходы.
Плюсы poll():
+ Hе содержит имманентного ограничения на максимальное
количество обслуживаемых сокетов.
+ Достаточно широкая портабельность.
Минусы poll():
- Менее эффективен, чем select() (так как передает в ядро
и назад по восемь байт на сокет) (Имплементация в Linux
использует особенно тормозной алгоритм обхода данных в poll())
Плюсы /dev/poll (Последние Solaris, патчи для Linux):
+ Hе имеет ограничения на максимальное количество обслуживаемых
сокетов.
+ Из-за модели передачи event'ов вместо модели передачи
состояний, очень эффективен при обслуживании большого количества
клиентов, только часть из которых очень активна (типичная
ситуация для web- и другого вида серверов). Состояния неактивных
сокетов не вызывают расхода ресурсов.
Минусы /dev/poll:
- Hе портабелен.
Плюсы kqueue/kevent (FreeBSD):
+ Hе имеет ограничения на максимальное количество обслуживаемых
сокетов.
+ Имеет "вкусные фичи", которые позволяют использовать его
более эффективным образом не только для сокетов, но и для
объектов другого типа (файлов, процессов).
Минусы:
- Hе портабелен.
- Линус Торвальдс его не любит.
Еще стоит посмотреть в сторону D.C. Schmidt'овкого ACE и JAWS,
если не в сторону первого так в сторону последнего как теоритетически -
экспериментального исследования...
Q: Пишу демона, если демон перезапускается - не может сделать bind()
A:
Смотреть в сторону setsockopt с опциями SO_REUSEADDR, SO_REUSEPORT.
SO_REUSEPORT есть не везде.
Q: Хочу ждать в треде одновременно mutex, event и поступление данных в пайп.
A:
Штатных средств нет. Лучше всего сделать свою прослойку, которая будет
для каждого треда держать сигнальный пайп и по, например, освобождению
mutex'а, кидать байтик в передающий конец пайпа той ветки, которой отдается
мьютекс. Есть несколько готовых прослоек такого рода.
Hу а несколько файловых объектов уже штатным образом ожидаются через
select/poll/kqueue.
Q: Чем ловить утечки памяти в программе на C:
A:
valgrind - очень мощное средство, только для Linux/x86.
LeakTracer
Electricfence
memprof
Q: Hадо ли проверять код возврата close()? А если вернется -1 и EINTR?
A:
Hадо. Проблемы возникают редко, но возникают.
Hапример, может прерваться происходящий по close() сброс буферов на NFS.
Для fclose() это еще более характерно.
Q: А как бы узнать, нажали ли кнопочку на клавиатуре?
A:
man curses; man curses_getch
Если curses неприменима - man termios
Q: Хочу таймеры. Man что?
A:
sleep
usleep
nanosleep
select
poll
(два последних - с пустыми наборами дескрипторов)
alarm
setitimer
eventlib
sleep, alarm - с точностью до секунды, остальные - точнее.
При необходимости точности более нескольких миллисекунд - бросать штатные
средства и искать realtime.
Q: Как писать оконные интерфейсы переносимо между Windows и Unix?
Какие toolkits для этого можно применять?
A: (Victor Wagner)
Информации о кроссплатформной переносимости тулкитов (возможности работы в
Windows и MacOS) я не привожу специально, так как считаю что писать
кроссплатформные GUI в большинстве случаев вредно. GUI должен быть удобен
пользователю. Пользователям Unix и оболочек дешевых удобно разное. Исключения
бывают, но редко.
=== end ===
