What will be status value in connect_cb of uv_tcp_connect(&connect_req, &h, addr, connect_cb)?

[parthasarathi204]

Hi,
How to handle the uv_tcp_connect() when uv_getaddrinfo() returns multiple addrinfo sturcture?
I am confused with the documentation which says that successful call to uv_tcp_connect() will ensure connect_cb callback.
https://github.com/libuv/libuv/pull/918/files
does that mean the status will be zero always? Does not look so.
plan is to call uv_tcp_connect() recursively with addresifo->ai_next in case of non-zero status in connect_cb.
Should we call uv_close(req->handle) before recursively calling ?

connect_cb(uv_connect_t *req, int status){
if (status) {
// close previously connected handle
// call uv_tcp_connect(addresifo->ai_next)
} else {
// connected. unfold the recursion
}
}

[bnoordhuis]

How to handle the uv_tcp_connect() when uv_getaddrinfo() returns multiple addrinfo sturcture?

You call uv_tcp_connect() for each record.

does that mean the status will be zero always?

If the TCP handshake succeeded, otherwise it's an error code.

Should we call uv_close(req->handle) before recursively calling ?

Yes, you should close the uv_tcp_t handle on error. It's possible for an error to be temporary and the uv_tcp_t to be in a reusable state, but it's easier to simply create a new one.

[parthasarathi204]

Thanks. I have two more question related to this.
1. I am using libuv(using libuv-0.10) in big code base where the loop has been created uv_loop_new() which internally calls uv__once_init();
uv_tcp_connect() goes through TCP handshake as expected if used as DLL in windows but if linked statically to libuv.a, I had to call uv__once_init(); from uv_tcp_init().

The binary structure is something like
a.exe
+-- 1.dll
+-- libuv.a ( libuv-0.10)
+-- 2.dll
+-- libuv.a (libuv-0.10)
+-- 3.dll
+-- libuv.a (libuv-0.10)

2. The same binary structure did not work in case of Macos
The difference between dynamic library scoping behaviors in UNIX, windows and macOS: Two-Level Namespaces.
https://developer.apple.com/library/archive/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html#//apple_ref/doc/uid/TP40002850-TPXREF116.

a.out
+-- 1.dylib
+-- libuv.a ( libuv-0.10)
+-- 2.dylib
+-- libuv.a (libuv-0.10)
+-- 3.dylib
+-- libuv.a (libuv-0.10)
Disabled this behavior (make it act like Linux) by specifying the -flat_namespace argument when compiling the dynamic library.
This works. But not completely out of trouble.
Another product 2.out wants to use (1.dylib, 2.dylib etc) but 2.out is linked with libuv 1.19

Surely, moving to same version libuv and linking dynamically is best but that is not possible for now. That is the reason we started linking statically so that multiple version libuv can be used.

2.out is working as expected for windows and linux, but not working for macos.

Any suggestion?