Remaining unbound functions

[squeek502]

• Add binding for uv_stream_get_write_queue_size #412 uv_stream_get_write_queue_size; see also the non-standard luv function tcp_write_queue_size, presumably bound before uv_stream_get_write_queue_size was added
• uv_loop_configure (Add binding and docs for uv_loop_configure #103, Add loop_configure binding #496)
• uv_setup_args (API luv.setup_args is missing #264); I don't think this is bindable, see RFC: fail gracefully in uv_{get,set}_process_title when uv_setup_args is not called libuv/libuv#2845
• Add binding for uv_fs_lchown #413 uv_fs_lchown
• uv_replace_allocator (no binding possible from Lua)
• uv_default_loop (we don't expose loop to Lua)
• uv_loop_new (we don't expose loop to Lua)
• uv_loop_delete (we don't expose loop to Lua)
• uv_loop_size (we don't expose loop to Lua)
• uv_loop_fork (we don't expose loop to Lua)
• uv_loop_get_data (we don't expose loop to Lua)
• uv_loop_set_data (we don't expose loop to Lua)
• uv_strerror (used internally but not bound externally)
• uv_strerror_r
• uv_err_name (used internally but not bound externally)
• uv_err_name_r
• uv_handle_size (don't think there's a usecase for this from Lua)
• uv_handle_get_type (Add handle_get_type and req_get_type #494)
• uv_handle_type_name (Add handle_get_type and req_get_type #494)
• uv_handle_get_data (no real reason to bind this imo)
• uv_handle_get_loop (we don't expose loop to Lua)
• uv_handle_set_data (no real reason to bind this imo)
• uv_req_size (don't think there's a usecase for this from Lua)
• uv_req_get_data (no real reason to bind this imo)
• uv_req_set_data (no real reason to bind this imo)
• uv_req_get_type (Add handle_get_type and req_get_type #494)
• uv_req_type_name (Add handle_get_type and req_get_type #494)
• uv_udp_set_source_membership (udp: Add udp_set_source_membership binding + improve udp_set_membership #491)
• uv_pipe_chmod (pipe: Add pipe_chmod binding #492)
• uv_process_get_pid (process: Add process_get_pid binding #493)
• uv_get_osfhandle
• uv_open_osfhandle
• uv_fs_get_type
• uv_fs_get_result (no real reason to bind this imo)
• uv_fs_get_ptr (no real reason to bind this imo)
• uv_fs_get_path
• uv_fs_get_statbuf (no real reason to bind this imo)
• uv_fs_get_system_error (Libuv >= 1.38.0, see Update submodule(LuaJIT,libuv) version #509 (comment))
• uv_ip4_addr (used internally but not bound externally)
• uv_ip6_addr (used internally but not bound externally)
• uv_ip4_name (used internally but not bound externally)
• uv_ip6_name (used internally but not bound externally)
• uv_ip_name
• uv_inet_ntop (used internally but not bound externally)
• uv_inet_pton
• uv_dlopen
• uv_dlclose
• uv_dlsym
• uv_dlerror

Threading/synchronization

Ignoring these for now; we aren't binding any of them currently AFAIK so it'd probably be opening a can of worms.

• uv_mutex_init
• uv_mutex_init_recursive
• uv_mutex_destroy
• uv_mutex_lock
• uv_mutex_trylock
• uv_mutex_unlock
• uv_rwlock_init
• uv_rwlock_destroy
• uv_rwlock_rdlock
• uv_rwlock_tryrdlock
• uv_rwlock_rdunlock
• uv_rwlock_wrlock
• uv_rwlock_trywrlock
• uv_rwlock_wrunlock
• uv_sem_init
• uv_sem_destroy
• uv_sem_post
• uv_sem_wait
• uv_sem_trywait
• uv_cond_init
• uv_cond_destroy
• uv_cond_signal
• uv_cond_broadcast
• uv_barrier_init
• uv_barrier_destroy
• uv_barrier_wait
• uv_cond_wait
• uv_cond_timedwait
• uv_once
• uv_key_create
• uv_key_delete
• uv_key_get
• uv_key_set

[SinisterRectus]

We could probably deprecate tcp_write_queue_size and getpid if they have libuv versions.

lchown needs implementing.

[squeek502]

What should be the process for deprecation?

[SinisterRectus]

I would just leave a comment in the code and document that it should not be used, or just not document it at all. We can't remove anything without a major version bump.

[squeek502]

Added to the OP: an autogenerated a list of all functions defined in uv.h that match the pattern UV_EXTERN return_type uv_function_name() that have no occurrences in any of Luv's C files. It's bigger than I was expecting, and it's likely that we don't really want to bind them all. Many have to do with threading/synchronization.

[zhaozg]

Brave man

[nikneym]

Are there any plans to expose loop utilities to Lua? I'm in a situation where I need to use fork syscall but in order to do that I have to call uv_loop_fork, where I need a pointer to loop. I know this is a niche case but it might still be effective to support loop calls.