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

[Valery Kholodkov]

Igor Sysoev пишет:

>> >Вот сигналов хотелось бы избежать.
>> Совсем.
>>
>> Почему?
>
> Потому что работать с обработчиками
> сигналов достаточно сложно - они,
> например, могут прийти в середине malloc()а.

Я же не предлагаю нагружать обработчик
сигнала
сложной логикой. Достаточно в
обработчике установить
флаг, и когда epoll_wait вернет EINTR и при
наличии
флага вызывать aio_return для всех aiocb, которые
были успешно приняты lio_listio.

> А ещё лучше работать с
> сигналами не обработчиками, а в виде
> событий, как в sigtimedwait().
> Поэтому идеально в обработчике просто
> выставлять атомарную переменную.
> Если же что-то более сложное, то нужно
> блокировать сигналы там, где
> они нежелательны, лучше как-то так:
>
> sigprocmask(SIG_UNBLOCK)
> kevent/epoll/select/poll/etc
> sigprocmask(SIG_BLOCK)
>
> Однако, тут возможен race condition, когда
> сигнал будет получен до
> kevent/etc, а мы можем надолго застрять в
> kevent/etc. То есть, нужно
> атомарное расблокирование сигнала и
> ожидание, как в pselect, ppoll.

kqueue имеет всторенный механизм ожидания
завершения
асинхронного дискового ввода-вывода, не
вижу смысла
не испольовать его.

-- 
Best regards,
Valery Kholodkov