I think we have to call the uv_handle_close on the TCP handle, and then wait for the connect to fail, not do a manual shutdown on the underlying descriptor, I wrote this to demonstrate what I mean:

#include <stdio.h>
#include <stdlib.h>
#include <uv.h>

static void
on_connect_cb(uv_connect_t *uv_connect, int status)
{
	printf("%s: %p status=%d (%s)\n", __func__, uv_connect, status, uv_strerror(status));
}

static void
on_timer_cb(uv_timer_t *uv_timer)
{
	uv_tcp_t *uv_socket = uv_handle_get_data((uv_handle_t *)uv_timer);
	
	printf("%s: uv_timer=%p uv_socket=%p\n", __func__, uv_socket,
	    uv_socket);
	uv_close((uv_handle_t *)uv_socket, (uv_close_cb)NULL);
}

int
main(void)
{
	uv_loop_t *loop = uv_default_loop();
	uv_tcp_t uv_socket;
	uv_connect_t uv_connect;
	struct sockaddr_in sin;
	uv_timer_t uv_timer;

	uv_tcp_init(loop, &uv_socket);
	uv_ip4_addr("142.250.186.174", 8080, &sin);

	uv_tcp_connect(&uv_connect, &uv_socket, (const struct sockaddr *)&sin,
	    on_connect_cb);

	uv_timer_init(loop, &uv_timer);
	uv_handle_set_data((uv_handle_t *)&uv_timer, &uv_socket);
	uv_timer_start(&uv_timer, on_timer_cb, 1000, 0);

	printf("Default loop.\n");
	uv_run(loop, UV_RUN_DEFAULT);

	uv_loop_close(loop);
	return (0);
}

This seems to be correct as the callback is called with UV_CANCELED:

sam:tmp: cc -o uv_connect_cancel uv_connect_cancel.c -Wall -luv && ./uv_connect_cancel; echo $?
Default loop.
on_timer_cb: uv_timer=0x7ffdd04f15b0 uv_socket=0x7ffdd04f15b0
on_connect_cb: 0x7ffdd04f14b0 status=-125 (operation canceled)
0

The manual describes the semantics:

       void uv_close(uv_handle_t *handle, uv_close_cb close_cb)
              Request  handle  to  be  closed.  close_cb will be called asynchronously after this call. This MUST be
              called on each handle before memory is released.   Moreover,  the  memory  can  only  be  released  in
              close_cb or after it has returned.

              Handles  that  wrap file descriptors are closed immediately but close_cb will still be deferred to the
              next iteration of the event loop.  It gives you a chance to free up any resources associated with  the
              handle.

              In-progress  requests,  like uv_connect_t or uv_write_t, are cancelled and have their callbacks called
              asynchronously with status=UV_ECANCELED.

@haesbaert : that sounds good. However, the tests hang if I do that!

I moved things around a bit and added a commented-out close call. Does it work for you if you uncomment it and do make test_luv?

@haesbaert : that sounds good. However, the tests hang if I do that!

I moved things around a bit and added a commented-out close call. Does it work for you if you uncomment it and do make test_luv?

You're right, and no, it's still hangs with/without the commented line :(

I noticed that make test_luv hangs once in a while in main/HEAD (355478d) as well, I didn't try tracking it yet.

Yeah, I'm not sure why the tests hang. Would be good to find out.

It would also be good to make it easier to find out, maybe by improving MDX, or by having Eio dump out some state on a signal or something. If you do EIO_BACKEND=luv dune runtest after a hanging build, the dune build log will at least tell you which test file it was (because it tries to rebuild only that one).

If you can capture a hanging case with rr record, that would be great!

Did some minor digging, it's not in MDX, it seems to hang on lib_eio_linux/tests/test.ml on the very first test:

(* Write a string to a pipe and read it out again. *)
let test_copy () =
  Printf.eprintf "COPY A\n";
  Eio_linux.run ~queue_depth:3 @@ fun _stdenv ->
  Switch.run @@ fun sw ->
  Printf.eprintf "COPY B\n";
  let msg = "Hello!" in
  let from_pipe, to_pipe = Eio_linux.pipe sw in
  let buffer = Buffer.create 20 in
  Printf.eprintf "COPY C\n";
  Fiber.both
    (fun () ->
       Printf.eprintf "COPY D1\n";
       Eio.Flow.copy from_pipe (Eio.Flow.buffer_sink buffer); (* XXXXX hangs here XXXXX *)
       Printf.eprintf "COPY D1A\n";
    )
    (fun () ->
       Printf.eprintf "COPY D2\n";
       Eio.Flow.copy (Eio.Flow.string_source msg) to_pipe;
       Printf.eprintf "COPY D2A\n";
       Eio.Flow.copy (Eio.Flow.string_source msg) to_pipe;
       Eio.Flow.close to_pipe;
       Printf.eprintf "COPY D2B\n";
    );
  Printf.eprintf "COPY D3\n";
  Alcotest.(check string) "Copy correct" (msg ^ msg) (Buffer.contents buffer);
  Printf.eprintf "COPY D4\n";
  Eio.Flow.close from_pipe;
  Printf.eprintf "COPY D5\n";
  Printf.eprintf "\nCOPY FINISHED!!!\n\n"

gives:

sam:eio_linux: cd $(pwd);  grep COPY io.000.output
COPY A
COPY B
COPY C
COPY D1
COPY D2
COPY D2A
COPY D2B

I'm running

        rm -rf _build
        EIO_BACKEND=luv dune runtest --always-show-command-line --verbose --no-buffer

Funny thing is I can't trigger with runtest -j1.

Be carefuil: Printf is buffered:

utop # Printf.eprintf "hi\n"; Unix.sleep 2;;
[ waits 2 seconds ]
hi
- : unit = ()

You can use %! to force a flush, or use Eio's traceln (which always flushes).

Be carefuil: Printf is buffered:

utop # Printf.eprintf "hi\n"; Unix.sleep 2;;
[ waits 2 seconds ]
hi
- : unit = ()

You can use %! to force a flush, or use Eio's traceln (which always flushes).

Ah yes, stupid me, I automatically assumed that eprintf was unbuffered, turns out I got lucky anyway, so it hangs because somehow the EOF is not seen by the reader Fiber, it reads "Hello" twice from the input pipe and then hangs forever waiting for the the EOF, if you put a sleep in the start of the writer, somehow it fixes, I didn't look much further.

That is odd! What happens if you just run ./_build/default/lib_eio_linux/tests/test.exe in a loop? It doesn't hang for me.

Given that the test hang is in code not affected by this (eio_luv) PR, and was occurring before, I propose to merge this as-is and open a new issue for the eio_linux test hang.

Given that the test hang is in code not affected by this (eio_luv) PR, and was occurring before, I propose to merge this as-is and open a new issue for the eio_linux test hang.

Yes please, sorry I got sidetracked.