Skip to content
This repository has been archived by the owner on May 4, 2018. It is now read-only.

Please expose bufs in uv_fs_t's result for uv_fs_read operations. #1557

Open
creationix opened this issue Oct 31, 2014 · 3 comments
Open

Please expose bufs in uv_fs_t's result for uv_fs_read operations. #1557

creationix opened this issue Oct 31, 2014 · 3 comments

Comments

@creationix
Copy link

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.

@creationix
Copy link
Author

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.

@saghul
Copy link
Contributor

saghul commented Nov 7, 2014

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 ;-)

@bnoordhuis
Copy link
Contributor

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants