Access client socket from Lwt_io.server callback

[rgrinberg]

This is something that async's TCP server provides for example:

https://github.com/janestreet/async_extra/blob/4da4ceceb537a6cb48c4cf6ef911486a67ab8626/src/tcp.mli#L212-L216

[aantron]

When looking at establish_server previously, I thought it might better belong in Lwt_unix and pass a socket to the callback.

[rgrinberg]

What's the difference? Lwt_io depnds on Lwt_unix anyway. An Lwt_server sounds like something that should be considered as well by the way. I don't think the difference between Lwt_io and Lwt_unix is so crystal clear today anyway.

[aantron]

It's just a note. There has been some discussion of making Lwt_io more analogous to the I/O section of Pervasives, so it would be available without the Unix binding. Lwt_io.establish_server then belongs in Lwt_unix or a truncated future Lwt_io, which would be analogous to Unix.establish_server. It should also pass a socket to the callback, because, unlike in Unix, Lwt does not provide a way to get the fd from the channel (would be analogous to Unix.descr_of_*_channel).

Alternatively, we could provide an option-valued function for getting Unix or Lwt_unix fds from Lwt_io channels.

[rgrinberg]

I see what you mean, but to be honest following the design of the stdlib on these matters seems like a non goal to me. IMO, the current organization of Lwt looks dated compared to more modern libraries such as async and bos. Both libraries provide a much better model for Lwt can look like.