-
Notifications
You must be signed in to change notification settings - Fork 521
-
If two threads use uring to write to stdout at the same time (using different rings), the write operation sometimes completes with EINTR (-4). Is this expected?
I can understand io_uring_enter itself returning EINTR, but I'm not sure what I'm supposed to do when an asynchronous job fails this way. Should uring itself be handling this?
Would be good to have this documented somewhere either way.
Thanks!
(this was originally reported at ocaml-multicore/eio#788)
Beta Was this translation helpful? Give feedback.
All reactions
You can probably eliminate this issue by using IORING_SETUP_DEFER_TASKRUN as I bet the -EINTR is coming from task_work being queued and signaled via signals.
Replies: 3 comments 1 reply
-
You can probably eliminate this issue by using IORING_SETUP_DEFER_TASKRUN as I bet the -EINTR is coming from task_work being queued and signaled via signals.
Beta Was this translation helpful? Give feedback.
All reactions
-
And yes, it might be possible to appropriately retry this condition. Let me ponder that a bit.
Beta Was this translation helpful? Give feedback.
All reactions
-
Indeed, IORING_SETUP_DEFER_TASKRUN makes the problem go away.
Beta Was this translation helpful? Give feedback.
All reactions
-
Not an answer, but a follow-up question --- would IORING_OP_TIMEOUT requests potentially return -EINTR too? I don't think there is an equivalent syscall for those, so I can't really tell if it might return EINTR errors by inferring from the equivalent syscall manpage.
If in the future a syscall is added to io_uring and that syscall is documented as NOT erroring with EINTR, would the io_uring version also NOT return -EINTR? (I can't remember offhand if there is any syscall that doesn't have EINTR but maybe there is one I just don't know about).
Beta Was this translation helpful? Give feedback.