unix, windows: pass structs by address, not value
Comments
Does it apply to callbacks like |
You mean functions/callbacks that take uv_buf_t structs? I'm undecided, depends on how hard it makes life for people. From an ABI perspective, there's no difference between So it depends on how difficult the current function prototype is to work with and how inflexible FFI implementations are. |
Yes, for example: Well, at the moment i have to deal with it this way: void net_on_read (uv_stream_t* tcp_handle, ssize_t nread, uv_buf_t buf) {
net_read_cb(tcp_handle, nread, &buf);
} And the final invocation: |
Right. What you can do as a workaround is to declare your function like this: void net_read_cb(uv_stream_t*, ssize_t, void* ptr, size_t len) {
// ...
} And call uv_start_read() like this: uv_read_start(stream, alloc_cb, (uv_read_cb) net_read_cb); Kind of hacky but it works because of the aforementioned calling convention rules. Admittedly, I don't know how complicated that is with Lua/LuaJIT's FFI (if it's possible at all.) |
I guess the above is a good argument for replacing uv_buf_t with explicit ptr/len parameters... |
@bnoordhuis I agree in general but not for uv_buf_t. |
While doing what this issue describes (txdv/libuv@165d729) I found some inconsistent error code behavior which I want to get rid of in a separate commit (#689) |
Why? |
@fillest FYI, I talked to the luajit author about this exact issue many months ago. His recommendation was to not use ffi with anything callback based at all. The callbacks make the ffi considerably slower, even if you work around the by-val struct references. My plan which I never found time to do, was to wrap the libuv API in a more poll style API where I repeadly call into libuv asking for the next event and it blocks till there is an event and then returns the event as a struct pointer. According to Mike, that should be lot faster than using the callback interface with ffi. But like I said, I never found time to write such a wrapper (in C) to libuv. |
@creationix Yeah I'm aware of it, I've read it many times. The funny thing is: there are no public benchmarks or profiling results which clearly shows it (correct me if I'm wrong), and it seems everybody just repeat this mantra :) It can be slow in absolute numbers but negligible in relative to other operations (so it may be critical for one application and irrelevant for another). |
@creationix and @fillest I also wanted to do a poll style wrapper for libuv for some time, and already started it, so if you can wait a little, maybe you don't have to write your own, if you find mine good enough. And of course, once I publish it (or even before that), suggestions are welcome :) |
What's the status of this feature? Is it getting in libuv in the near future? |
Depends on your definition of 'near future'. After node.js v0.10 at the earliest. |
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Passing or returning structs as values makes life hard for people that work with libuv through a foreign function interface. Switch to a pointer-based approach. Fixes #684.
Excellent! Time to give wrapping libuv in lisp another shot. Thanks. |
bnoordhuis commentedJan 15, 2013
Functions like uv_tcp_bind() and uv_tcp_connect() take a struct sockaddr_in as a value, make them use pointers instead.
Why?
uv_tcp_bind(struct sockaddr_in)
anduv_tcp_bind(struct sockaddr_in6)
becomeuv_tcp_bind(struct sockaddr*)
(that's what happens internally anyway).Target v0.12.
/cc @piscisaureus
The text was updated successfully, but these errors were encountered: