uv_open

[txdv]

I was looking into the code and one thing stood out in my eyes: we have functions like uv_write and uv_fileno which basically accept any kind of handle and dependent on the type of it (which is a basically a variable in the struct) it determines what to do.

Yet we have multiple functions for opening an already existing file descriptor: uv_tcp_open, uv_udp_open.

The most annoying part IMO is that there is no uv_tty_open, even though the constructor of uv_tty_init requires a file descriptor. I think we could move the functionality of opening a file descriptor in a tty to open.

I think creating uv_open would make writing bindings easier, because currently it kinda is a lot of code.

[txdv]

Ok, after further investigation, the signatures are a bit different:

UV_EXTERN int uv_udp_open(uv_udp_t* handle, uv_os_sock_t sock);
UV_EXTERN int uv_tcp_open(uv_tcp_t* handle, uv_os_sock_t sock);
UV_EXTERN int uv_pipe_open(uv_pipe_t*, uv_file file);

On windows uv_os_sock_t is SOCKET. Don't know what to make of it.

[saghul]

This would indeed be nice, specially on Unix, there everything is a fd. On Windows, however, we have a problem, which I don't know how to solve elegantly. AFAIK all SOCKET and HANDLEs can be stored as 32bit integers, because even on 64bit Windows, handles only use the lest signifficant 32bits, but it sounds too much like a hack.

[txdv]

We could use IntPtr and cast to Int on unix only.

[saghul]

That's just reversing the hack :-S

[txdv]

But there is no possible way we loose precision that way

[saghul]

I still think we're trying to force it here. Not to mention intptr_t is a C99-ism, IIRC.

While I like the idea, I don't like how the implementation would result, so lets stick with the different functions we have for now.

[txdv]

I agree, this is the way C libs work