You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 4, 2018. It is now read-only.
In my bindings, uv_fs_read is the only place in all of libuv where I have to externally track the read buffer to get the result. In others like uv_read, the callback gives me a uv_buf_t which contains the buffer I allocated for the read (in uv_alloc_cb). This makes is easy to both get the result and free my data when I'm done.
It would be awesome and save me a pointer in my reqs if uv_fs_read did the same thing and gave me back the buffer somehow in the result. It appears the req->ptr member isn't used for anything in this fs operation but I'm not entirely sure how you would fit both the bufs array and the length of the array.
For my uses, the array is always length 1 so that's not a problem.
The text was updated successfully, but these errors were encountered:
Also it appears that there are already private members containing the bufs and the number of bufs. If these were simply added to the public API, that would be enough.
You can embed your uv_fs_t struct into another one and use container_of to grab a pointer to it on the callback.
This is the same design principle taken for uv_write for example. I don't recall what the reasons behind this were, maybe @bnoordhuis can clarify, but IIRC it has been like this from the start and the use of structure embedding is recommended.
Now, between you and I, those fields are not going away on 1.x ;-)
I don't recall what the reasons behind this were, maybe @bnoordhuis can clarify, but IIRC it has been like this from the start and the use of structure embedding is recommended.
Embedding allows for compact structures that can be freed in one go. It eliminates the possibility of dangling pointers. Embedding is generally also a bit faster than pointer chasing, although that's mostly irrelevant in libuv.
Having public API accessors would be a good thing. It lets us move things around in the future without having to worry about breakage and it's arguably all around cleaner than letting people grub around in your private parts, amirite?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In my bindings,
uv_fs_read
is the only place in all of libuv where I have to externally track the read buffer to get the result. In others likeuv_read
, the callback gives me auv_buf_t
which contains the buffer I allocated for the read (inuv_alloc_cb
). This makes is easy to both get the result and free my data when I'm done.It would be awesome and save me a pointer in my reqs if
uv_fs_read
did the same thing and gave me back the buffer somehow in the result. It appears thereq->ptr
member isn't used for anything in this fs operation but I'm not entirely sure how you would fit both the bufs array and the length of the array.For my uses, the array is always length 1 so that's not a problem.
The text was updated successfully, but these errors were encountered: