Вопрос по б??дущему кэш??рованию.

[Igor Sysoev]

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