Strange issue with Lwt_unix.wait_read not waiting when called from a compiled binary

Ecosystem
1

I may be wrong about the nature of the issue, or I may simply be missing something stupid. Here’s a simplified version of the code in question:

let do_request sock ic oc msg =
  let%lwt () = Lwt_unix.wait_write sock in
  let%lwt () = Message.write oc msg in
  let%lwt () = Lwt_unix.wait_read sock in
  let%lwt resp = Message.read ic in
  Lwt.return resp

From the REPL, it works as expected, even though it takes a lot more time than I’d expect (on the order of seconds). In the compiled binary, however, it exits with 0 right at the Lwt_unix.wait_read.
On the server side I see that the request message is received by the server, but then it tries to send a reply, the client program has already exited and it gets a SIGPIPE.

Any suggestions how to debug this?

1 Like
2

@dmbaturin, could you provide a self-contained example, i.e. something complete that we can run to reproduce the issue? This would be my first suggestion, if you’d like to proceed by debugging with the aid of others :slight_smile:

I don’t see anything inherently wrong with the code you have posted itself.

3

We resolved this on IRC the other day. The summary is the program wasn’t calling Lwt_main.run, which is the Lwt “scheduler” (I/O loop), which must be called in programs that do I/O. Otherwise, the process will simply exit after starting some initial I/O.

3 Likes
4

I assumed that in a one shot program that doesn’t really have a main loop, one can get away with not using Lwt_main.run
Now I realize how wrong that idea was. :wink: