[all-commits] [llvm/llvm-project] a8e3c0: [libc] fix EAGAIN being treated as timeout in mute...

[Schrodinger ZHU Yifan via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a8e3c083db160e2dc6f04b660b22b459e5167199
      https://github.com/llvm/llvm-project/commit/a8e3c083db160e2dc6f04b660b22b459e5167199
  Author: Schrodinger ZHU Yifan <yfzhu at google.com>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    M libc/src/__support/threads/linux/futex_utils.h
    M libc/src/__support/threads/raw_mutex.h
    M libc/src/__support/threads/raw_rwlock.h
    M libc/test/integration/src/__support/threads/futex_requeue_test.cpp

  Log Message:
  -----------
  [libc] fix EAGAIN being treated as timeout in mutex and rwlock (#203574)

fix #203411. 

This PR addresses the problem that `EAGAIN` may be treated as timeout in
mutex and rwlock. Two changes are applied:

1. timeout sites always explicitly check for timeout now to make the
logic more robust;
2. the futex wait now discards the error of `EAGAIN/EWOULDBLOCK` and
returns 0;

We don't distinguish waking up from signal and waking up from mismatch
for the following 3 reasons:
- We have userspace guard to avoid futex syscall if we already know
value would match, it seems awkward to make that check returns error, as
we may wake up and loop back to the check, where signal is consumed but
we still return error....;
- futex syscall can spuriously wake up anyway, there is no way to tell
whether the signal is "indeed" consumed;
- other platforms like darwin does not distinguish these states either.

Assisted-by: Gemini powered automation tools (human-in-the-loop).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications