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
I'm not sure if it's worth the efforts. However it looks a bit quirky that one needs to keep a struct __kernel_timespec alive until the submission is fully done.
I feel it would be nice to have a flag like IORING_TIMEOUT_PURE_NS, and encode its value in the addr field.
An alternative could be normalizing the timespec so that the tv_nsec is less than 999'999'999. We could take it to some i32 field in the sqe. I don't see any use of fields from the union with splice_fd_in for TIMEOUTs...
BTW, unlike timerfd_settime(), the uring implementation is currently not strict and doesn't reject if tv_nsec > 999'999'999. Could it be documented, or you need a freedom to make it stricter in the future?
The text was updated successfully, but these errors were encountered:
vsolontsov-ll
changed the title
IORING_OP_TIMEOUT / IORING_OP_TIMEOUT_REMOVE. Consider allowing a single int64 asa timeout.
IORING_OP_TIMEOUT / IORING_OP_TIMEOUT_REMOVE. Consider allowing a single int64 a sa timeout.
Apr 4, 2024
vsolontsov-ll
changed the title
IORING_OP_TIMEOUT / IORING_OP_TIMEOUT_REMOVE. Consider allowing a single int64 a sa timeout.
IORING_OP_TIMEOUT / IORING_OP_TIMEOUT_REMOVE. Consider allowing a single int64 as a timeout.
Apr 5, 2024
I'm not sure if it's worth the efforts. However it looks a bit quirky that one needs to keep a
struct __kernel_timespec
alive until the submission is fully done.I feel it would be nice to have a flag like
IORING_TIMEOUT_PURE_NS
, and encode its value in theaddr
field.An alternative could be normalizing the timespec so that the
tv_nsec
is less than 999'999'999. We could take it to some i32 field in thesqe
. I don't see any use of fields from the union withsplice_fd_in
for TIMEOUTs...BTW, unlike
timerfd_settime()
, the uring implementation is currently not strict and doesn't reject iftv_nsec > 999'999'999
. Could it be documented, or you need a freedom to make it stricter in the future?The text was updated successfully, but these errors were encountered: