Anton Bachin

> I bet libuv offers rich API for communicating across threads [`uv_async_t`](http://docs.libuv.org/en/v1.x/async.html) for delivering a message to another loop (potentially in another thread). The OCaml version is [`Luv.Async`](https://aantron.github.io/luv/luv/Luv/Async/index.html). It may...

As I understand it, code shouldn't be linked against two versions of libuv or two instances of libuv at all. Ideally, the whole project could be configured to use the...

For `ocaml-hiredis`, you would simply have the adapter depend on `luv` (or just `lwt` like it already does, if/when `lwt` itself depends on `luv`, though you may still want to...

> This is not entirely related, but would it be possible to take this opportunity to introduce a `lwt_unix` package? Yes, this seems like a good opportunity to do so....

Interested to see what you have made. Also, it would be nice to run CI tests even of only the existing platform-independent parts of Lwt on Node (see #249). Would...

I want this. Any word? Ideally, we would make room for several bindings besides Unix, though practically we would implement the ones that people are most interested in first. Ideally,...

I'd rather avoid a special version of `try_bind` just for signals. It won't solve the problem of surprising behavior of the existing `try_bind`, but be another thing to learn. I...

And welcome back :)

Agreed on the notes to be added to the manual. There isn't really a reviewable draft posted yet. There is a project instead of an issue: https://github.com/ocsigen/lwt/projects/2. And agreed on...

@XVilka The current status of this issue is summarized above and by @gaborigloi in https://discuss.ocaml.org/t/565/9. I think the overall state for now is that this is difficult to solve and...