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
A lock another holder has is 'again', not an input-output failure
⚠️⚠️ THE TRANSLATION TABLE HAD NO ENTRY FOR A LOCK CONFLICT, because nothing in
this implementation took a lock until openkal 0.10.
`kal_fs_lock' without KAL_LOCK_WAIT reports `kal_err_again' where the range is
held --- that is the answer a caller POLLS UPON, and openkal says so. Without the
entry, `ERROR_LOCK_VIOLATION' fell to the default arm and became `kal_err_io':
a failure of the DEVICE rather than a conflict with another holder. A caller
reading that stops; a caller reading `again' retries.
⭐ IT IS DISTINCT FROM `ERROR_SHARING_VIOLATION', WHICH STAYS `permission'.
That one is a conflict over how a file was OPENED and is not resolved by asking
again. Two errors that look adjacent and mean opposite things for a caller.
Found by the specification's own conformance suite, on the observation added with
the operation --- which is the argument for adding the observation with the
operation.
0 commit comments