Я читаю Либув книга, однако раздел о проверке и подготовке наблюдателей неполон, поэтому единственная информация, которую я нашел, была в ув.h:
/ * * uv_prepare_t является подклассом uv_handle_t. * * Каждый активный дескриптор подготовки получает свой обратный вызов, вызываемый ровно один раз за цикл * итерация, непосредственно перед тем, как системные блоки ожидают завершения ввода-вывода. * /
а также
/ * * uv_check_t является подклассом uv_handle_t. * * Каждый активный дескриптор проверки получает свой обратный вызов, вызываемый ровно один раз за цикл * итерация, сразу после того, как система вернется из блокировки. * /
Мне было интересно, есть ли какое-либо специальное использование проверки libuv и подготовки наблюдателей.
Я пишу нативную привязку node.js к библиотеке c ++, которая должна обрабатывать события, запускаемые из разных потоков, поэтому, естественно, обратные вызовы должны вызываться из основного потока. Я пытался с помощью uv_async_t
Однако libuv не гарантирует, что обратный вызов будет вызываться один раз за каждый uv_async_send
так что это не работает для меня.
Вот почему я решил пойти со своей собственной потокобезопасной очередью событий, которую я хочу периодически проверять. Поэтому мне было интересно, подойдет ли для этой цели проверка или подготовка наблюдателя.
На самом деле, мое текущее решение действительно использует uv_async_t
наблюдатель — каждый раз, когда я получаю событие, я помещаю его в очередь а также вызов uv_async_send
— поэтому, когда обратный вызов, наконец, вызывается, я обрабатываю все события, которые в данный момент находятся в очереди.
Моя проблема с этим подходом заключается в том, что многие события могут на самом деле стоять в очереди до тех пор, пока не сработает обратный вызов, и могут тем временем стать недействительными (под аннулированием я имею в виду, что с этой точкой обращаться с ними становится бессмысленно).
Поэтому я хочу иметь возможность проверять очередь событий как можно чаще — что могут предоставить наблюдатели проверки / подготовки, но может быть, это излишне делать это (и блокировать мьютекс) на каждой итерации цикла событий?
И, что более важно, может быть, они должны служить какой-то более специальной цели, чем просто обеспечение обратного вызова один раз за цикл итерации?
Спасибо
Вы можете использовать дескриптор prepare для проверки своей очереди на наличие событий и асинхронный дескриптор только для пробуждения цикла.
Если вы используете только дескриптор подготовки, вы можете оказаться в ситуации, когда цикл заблокирован для ввода-вывода, и никто не будет обрабатывать очередь до тех пор, пока он не завершит опрос. Асинхронный дескриптор «разбудит» цикл, и при следующем запуске дескрипторов подготовки вы обработаете очередь.
Других решений пока нет …