Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Вопрос по б??дущем у кэш??рованию.
On Thu, May 08, 2008 at 10:29:27AM +0200, Valery Kholodkov wrote:
>
> Igor Sysoev пишет:
>
> >> >Вот сигналов хотелось бы избежать.
> >> Совсем.
> >>
> >> Почему?
> >
> > Потому что работать с обработчиками
> > сигналов достаточно сложно - они,
> > например, могут прийти в середине malloc()а.
>
> Я же не предлагаю нагружать обработчик
> сигнала
> сложной логикой. Достаточно в
> обработчике установить
> флаг, и когда epoll_wait вернет EINTR и при
> наличии
> флага вызывать aio_return для всех aiocb, которые
> были успешно приняты lio_listio.
Race condition в данном случае в том, что флаг может быть выставлен
до epoll_wait, а потом epoll будет ждать какое-то время.
> > А ещё лучше работать с
> > сигналами не обработчиками, а в виде
> > событий, как в sigtimedwait().
> > Поэтому идеально в обработчике просто
> > выставлять атомарную переменную.
> > Если же что-то более сложное, то нужно
> > блокировать сигналы там, где
> > они нежелательны, лучше как-то так:
> >
> > sigprocmask(SIG_UNBLOCK)
> > kevent/epoll/select/poll/etc
> > sigprocmask(SIG_BLOCK)
> >
> > Однако, тут возможен race condition, когда
> > сигнал будет получен до
> > kevent/etc, а мы можем надолго застрять в
> > kevent/etc. То есть, нужно
> > атомарное расблокирование сигнала и
> > ожидание, как в pselect, ppoll.
>
> kqueue имеет всторенный механизм ожидания
> завершения
> асинхронного дискового ввода-вывода, не
> вижу смысла
> не испольовать его.
Да, в случае kqueue нужно использовать её.
--
Игорь Сысоев
http://sysoev.ru
|
