This should fix termination with applications using epollcat and cats-effect.
There is a bug (not sure if it's intended or not) in Unit's nxt_unit_process_port_msg which returns NXT_UNIT_AGAIN even if there are still messages to process. So I added a workaround which is to manually check if there are still bytes to process in the file descriptor.
This fixes the termination problem in imperative applications using epollcat.
Fixed that there was still a problem with http4s since our Resource, constructed with Resource.eval was not terminating.
There is no way that I know in cats-effect to wait until all the processing has been done in epollcat's event loop. To mitigate this, I keep track of all the ports I stopped. When all the ports are stopped I call a shutdownHandler which completes a Deferred with the function which then calls the final nxt_unit_done(ctx) and terminates the application gracefully.
This should fix termination with applications using epollcat and cats-effect. There is a bug (not sure if it's intended or not) in Unit's
nxt_unit_process_port_msgwhich returnsNXT_UNIT_AGAINeven if there are still messages to process. So I added a workaround which is to manually check if there are still bytes to process in the file descriptor. This fixes the termination problem in imperative applications using epollcat. Fixed that there was still a problem with http4s since ourResource, constructed withResource.evalwas not terminating. There is no way that I know in cats-effect to wait until all the processing has been done in epollcat's event loop. To mitigate this, I keep track of all the ports I stopped. When all the ports are stopped I call ashutdownHandlerwhichcompletes aDeferredwith the function which then calls the finalnxt_unit_done(ctx)and terminates the application gracefully.