Hezekiah M. Carty

This would be quite useful. int and float versions as well. I've used each of these in manual form when working with external libraries.

If I add a line inside the `server` definition to limit the number of conduit active connections the leak isn't eliminated but it is reduced to a few megabytes leaked...

I take back my comment that the leak isn't eliminated when `Conduit_lwt_server.set_max_active` is used - the memory usage grows with the maximum number of concurrent connections attempted but it caps...

If you install libev and the conf-libev opam package then you should be able to handle far more connections. That will cause Lwt to use libev rathe than select for...

@ciarancourtney I was about to suggest `set_max_active` - I've had to do the same for projects locally. Glad those two fixed the crash.

@aantron There are a few parts to this. Even with libev the issue will come up if `set_max_active` isn't used and there are a large number of open connections. Same...

@fdopen Thank you for the explanation!

I second the preference for cstruct over core_kernel.

Are there any plans to continue/revive this? It would be very nice to have a Unix-based cohttp available.

Could this go into a `CCProcess` or similar module under `containers.threads`? It could provide similar functionality to Lwt's https://ocsigen.org/lwt/3.1.0/api/Lwt_process