From @jonathanstowe

Hi,
In a number of places in the design documents it is suggested that certain functionality on files (e.g. fcntl, ioctl) or sockets (e.g. getsockname, setsockopt) should be provided by external modules via the NativeCall interface, however the majority of these C library functions require the native "file descriptor" as one of the arguments.

It would be useful to module authors if the OS platform (or runtime environment) idea of a "file descriptor" was available through some accessor on the IO​::Handle, IO​::Socket etc

Where libuv is being used then this is available through

  int uv_fileno(const uv_handle_t* handle, uv_os_fd_t* fd)

If libuv is being bypassed for sync operations at some later point then the descriptor will be available directly.

My personal fear is that if this is not provided for the use in modules that require them then people will just bypass IO​::* altogether creating an interoperability nightmare.

Thanks.

From @jnthn

On Mon Nov 02 10​:54​:27 2015, jns+bc@​gellyfish.co.uk wrote​:

Hi,
In a number of places in the design documents it is suggested that
certain functionality on files (e.g. fcntl, ioctl) or sockets (e.g.
getsockname, setsockopt) should be provided by external modules via
the NativeCall interface, however the majority of these C library
functions require the native "file descriptor" as one of the
arguments.

It would be useful to module authors if the OS platform (or runtime
environment) idea of a "file descriptor" was available through some
accessor on the IO​::Handle, IO​::Socket etc

Where libuv is being used then this is available through

int uv_fileno(const uv_handle_t* handle, uv_os_fd_t* fd)

If libuv is being bypassed for sync operations at some later point
then the descriptor will be available directly.

My personal fear is that if this is not provided for the use in
modules that require them then people will just bypass IO​::*
altogether creating an interoperability nightmare.

Agree, it's wise to provide a way to get it for such scenarios. Added a .native-descriptor on file handles and sockets now. As the name suggests, it's native, as in platform specific (so you can expect to get a HANDLE value on Windows, for example). Tests in S32-io/native-descriptor.t.

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'