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.
Right now, libuv sees the EPOLLHUP but still does the alloc_cb -> read(2) -> read_cb dance, which is rather inefficient.
Short-circuiting is easy to do but it means we'll be calling read_cb with a null buffer that hasn't been allocated with alloc_cb. That's not really a breach of contract (depending on how you look at it; the documentation says "The callee is responsible for freeing the buffer, libuv does not reuse it.") but it's possible that not all libuv users expect that. Ergo, document that clearly in the release notes.
The text was updated successfully, but these errors were encountered:
Note that uv-win already requires the user to this about this. When an error is passed to the read_cb it may or may not include an allocated buffer. That said, it never passes a null buffer when the error is UV_EOF, so clearly documenting this would be a good thing.
Right now, libuv sees the EPOLLHUP but still does the alloc_cb -> read(2) -> read_cb dance, which is rather inefficient.
Short-circuiting is easy to do but it means we'll be calling read_cb with a null buffer that hasn't been allocated with alloc_cb. That's not really a breach of contract (depending on how you look at it; the documentation says "The callee is responsible for freeing the buffer, libuv does not reuse it.") but it's possible that not all libuv users expect that. Ergo, document that clearly in the release notes.
The text was updated successfully, but these errors were encountered: