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
While investigating why nonblocking does not seem to work exactly right for unix sockets, I found that the flags seem to be getting garbled by the existing setBlocking logic.
For logic that sets it to nonblock, the flags start as 2, then with O_NONBLOCK they become 6 and are set back into fcntl. By the time it tries to set it blocking again, the flags are nonsense. Once I saw 194, and another time 491294 or something like that.
By contrast a version using the fcntl bound by jnr-posix seems to properly set it to 6 and back to 2.
The text was updated successfully, but these errors were encountered:
After matching jnr-posix, this fixes issues setting blocking mode
reported in jnr#44.
Exercise for the future would be to only have one definition of
these methods in the jnr tree.
headius
added a commit
to headius/jnr-enxio
that referenced
this issue
Jul 17, 2024
While investigating why nonblocking does not seem to work exactly right for unix sockets, I found that the flags seem to be getting garbled by the existing
setBlocking
logic.For logic that sets it to nonblock, the flags start as 2, then with O_NONBLOCK they become 6 and are set back into fcntl. By the time it tries to set it blocking again, the flags are nonsense. Once I saw 194, and another time 491294 or something like that.
By contrast a version using the fcntl bound by jnr-posix seems to properly set it to 6 and back to 2.
The text was updated successfully, but these errors were encountered: