В любом случае спасибо за комментарии :) Это подтолкнуло меня к тому чтобы ещё раз взглянуть на модули nginx'а, и нашёл то чего мне так нехватало(из-за незнаний) в nginx'е, уже сел писать модуль для связки с erlang node'ами.
>но я до сих пор не вполне понимаю, зачем это может понадобиться.
Мне самому это не надо, так как всё это делаю в других процессах(чтобы не убить хттп сервер своими ошибками), но если уж перл внутри nginx'а крутится, то работа c IO вполне возможна и желательно чтобы она не мешала остальным клиентам.
Запись в лог — это самая примитивная задача, которой желательно выполняться синхронно.
В nginx'е насколько понимаю(а я плохо понимаю) такую задачу придётся выносить в отдельный процесс и использовать «upstream handler».
В случае с лёгкими userspace тредами всё решается просто и удобно(ну как в Plan9), но получаем большее потребление памяти для стека. Так что проблема с блокирующими вызовами — это проблема nginx'а, а не подхода в котором используется aio и треды ядра == кол-ву логических процессоров.
>Я имел в виду epoll
Это всё же не средство для выполнения быстрых асинхронных системных вызовов, а «I/O event notification facility».
Асинхронные системные вызовы — это надо смотреть в сторону syslets/threadlets/итд.
ну и libaio работает через сигналы ;)
И я бы epoll назвал не быстрым, а масштабирующимся.
>У этого подхода есть и свои недостатки, главными из которых можно назвать необходимость очень тщательного подхода к программированию сервера, и отсутствие возможности использовать блокирующиеся операции ввода-вывода.
А можно как-нибудь сделать асинхронный вызов записи в лог из своего собственного модуля, а потом дождаться пока не произойдёт запись и продолжить работу в текущем соединении/клиенте? Если нет, то я бы назвал основным недостатком — отсутствие гибкости, так как приходиться жить в конечном автомате nginx'а и никуда не сворачивать :)
>И даже средства для выполнения быстрых асинхронных системных вызовов появились в Linux, FreeBSD и Windows относительно недавно (я не имею в виду select и poll).
А какие средства вы имеете в виду? ну к примеру в Linux.
Очень удобно работать с текстовыми буфферами, в которых постояно происходит брейнсторминг и рождаются задачи. В mylyn эти визарды/деревяшки задач — точно не для меня…
А вы использовали emacs+org-mode перед тем как предлагать Mylyn?
Я использовал mylyn, если это и есть настоящее юзабилити, то лучше останусь на org-mode ;)
Основная проблема наши студентов в том что они считают что где-то там далеко всё иначе :) Сразу вспоминается статья Steve Yegge, где он упоминал о том какие выпускники приходят устраиваться в гугл/амазон/где он там ещё работал, вроде и Ph.D и выпустились из МТИ, а даже базовых знаний то не особо.
-export([start/0]).
start() -> lists:foldl(fun(I, R) -> lists:foldl(fun(J, R2) -> (R2 + (I * J) rem 100) rem 47 end, R, lists:seq(0, 10000)) end, 0, lists:seq(0, 10000)).
Eshell V5.7.2 (abort with ^G)
1> c(test).
{ok,test}
2> timer:tc(test, start, []).
{31674407,39}
31сек
Мне самому это не надо, так как всё это делаю в других процессах(чтобы не убить хттп сервер своими ошибками), но если уж перл внутри nginx'а крутится, то работа c IO вполне возможна и желательно чтобы она не мешала остальным клиентам.
В nginx'е насколько понимаю(а я плохо понимаю) такую задачу придётся выносить в отдельный процесс и использовать «upstream handler».
В случае с лёгкими userspace тредами всё решается просто и удобно(ну как в Plan9), но получаем большее потребление памяти для стека. Так что проблема с блокирующими вызовами — это проблема nginx'а, а не подхода в котором используется aio и треды ядра == кол-ву логических процессоров.
Это всё же не средство для выполнения быстрых асинхронных системных вызовов, а «I/O event notification facility».
Асинхронные системные вызовы — это надо смотреть в сторону syslets/threadlets/итд.
ну и libaio работает через сигналы ;)
И я бы epoll назвал не быстрым, а масштабирующимся.
>У этого подхода есть и свои недостатки, главными из которых можно назвать необходимость очень тщательного подхода к программированию сервера, и отсутствие возможности использовать блокирующиеся операции ввода-вывода.
А можно как-нибудь сделать асинхронный вызов записи в лог из своего собственного модуля, а потом дождаться пока не произойдёт запись и продолжить работу в текущем соединении/клиенте? Если нет, то я бы назвал основным недостатком — отсутствие гибкости, так как приходиться жить в конечном автомате nginx'а и никуда не сворачивать :)
А какие средства вы имеете в виду? ну к примеру в Linux.
Я использовал mylyn, если это и есть настоящее юзабилити, то лучше останусь на org-mode ;)
вот ещё один такой www.blerp.com