Remaining unbound functions

[squeek502]

• [x] https://github.com/luvit/luv/pull/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
• [x] uv_loop_configure (#103, https://github.com/luvit/luv/pull/496)
• [ ] uv_setup_args (#264); I don't think this is bindable, see https://github.com/libuv/libuv/issues/2845
• [x] #413 uv_fs_lchown
• [x] ~~uv_replace_allocator~~ (no binding possible from Lua)
• [x] ~~uv_default_loop~~ (we don't expose loop to Lua)
• [x] ~~uv_loop_new~~ (we don't expose loop to Lua)
• [x] ~~uv_loop_delete~~ (we don't expose loop to Lua)
• [x] ~~uv_loop_size~~ (we don't expose loop to Lua)
• [x] ~~uv_loop_fork~~ (we don't expose loop to Lua)
• [x] ~~uv_loop_get_data~~ (we don't expose loop to Lua)
• [x] ~~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
• [x] ~~uv_handle_size~~ (don't think there's a usecase for this from Lua)
• [x] uv_handle_get_type (https://github.com/luvit/luv/pull/494)
• [x] uv_handle_type_name (https://github.com/luvit/luv/pull/494)
• [x] ~~uv_handle_get_data~~ (no real reason to bind this imo)
• [x] ~~uv_handle_get_loop~~ (we don't expose loop to Lua)
• [x] ~~uv_handle_set_data~~ (no real reason to bind this imo)
• [x] ~~uv_req_size~~ (don't think there's a usecase for this from Lua)
• [x] ~~uv_req_get_data~~ (no real reason to bind this imo)
• [x] ~~uv_req_set_data~~ (no real reason to bind this imo)
• [x] uv_req_get_type (https://github.com/luvit/luv/pull/494)
• [x] uv_req_type_name (https://github.com/luvit/luv/pull/494)
• [x] uv_udp_set_source_membership (https://github.com/luvit/luv/pull/491)
• [x] uv_pipe_chmod (https://github.com/luvit/luv/pull/492)
• [x] uv_process_get_pid (https://github.com/luvit/luv/pull/493)
• [ ] uv_get_osfhandle
• [ ] uv_open_osfhandle
• [ ] uv_fs_get_type
• [x] ~~uv_fs_get_result~~ (no real reason to bind this imo)
• [x] ~~uv_fs_get_ptr~~ (no real reason to bind this imo)
• [ ] uv_fs_get_path
• [x] ~~uv_fs_get_statbuf~~ (no real reason to bind this imo)
• [ ] uv_fs_get_system_error (Libuv >= 1.38.0, see https://github.com/luvit/luv/pull/509#issuecomment-686148354)
• [ ] 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