Первое, что приходит в голову: чтобы не занимать worker thread надо использовать inprocess thread. Если же для генерации результата используется блокирующий процесс (сетевой ввод/вывод и т.п.), то задействовать под него рабочий поток (наверное стоит создать свой пул, чтобы не конфликтовать с пулом nxweb). Либо можно основной обработчки сделать inprocess, а по событиям добавлять в очередь подзапросы, для которых уже будут задействованы рабочие потоки. Наверное так даже лучше. В качестве примера можно посмотреть ssi_filter. Он инициирует подзапросы для всех инклудов, а потом по мере созревания ответов подключает их в очередь на выдачу.
Важный вопрос - откуда будут поступать события? Если из других потоков, то нужно использовать что-то типа eventfd (который сейчас используется для оповещении inprocess потока о том, что worker выполнил задание). А раз это другой поток, то не выполнить ли в нем заодно и все блокирующие операции, чтобы в те соединения, которые ждут события, пришел уже готовый результат, который осталось бы лишь отправить клиенту?
Еще надо не забывать отключать write timeout (либо увеличить его) для соответствующих запросов, т.к. это защитное средство отрубит все, что не завершилось в срок. А если отключить его, то стоит подумать о какой-то другой защите от зависших соединений.
В общем, все это реализуемо, но надо глубоко вникать в работу nxweb.