wait_event_..._irq_timeout(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

wait_event_..._irq_timeout(9) πŸ’…βœ¨

Okay so this is from the Kernel API Manual, and it's the page for wait_event_interruptible_lock_irq_timeout β€” literally the function that puts your process to sleep until a condition gets true or a timeout elapses. The condition is checked under the lock, and this is expected to be called with the lock taken, periodt. 🫢


πŸ’– NAME πŸ’–

wait_event_interruptible_lock_irq_timeout β€” sleep until a condition gets true or a timeout elapses. The condition is checked under the lock. This is expected to be called with the lock taken. No cap, that lock detail is the whole vibe. πŸ’…


✨ SYNOPSIS ✨

Here's the exact call, bestie β€” do not freestyle the spacing, I'm begging:

wait_event_interruptible_lock_irq_timeout (wq_head , condition , lock ,
timeout );

πŸŽ€ ARGUMENTS πŸŽ€

Argument vibe check, one by one:

  • wq_head β€” the waitqueue to wait on. This is the main character waitqueue, okay? πŸ‘‘
  • condition β€” a C expression for the event to wait for. Like, the thing your whole nap is about. πŸ’€
  • lock β€” a locked spinlock_t, which will be released before schedule and reacquired afterwards. Yes, it really does the lock handoff. πŸ”
  • timeout β€” timeout, in jiffies. That's the unit, bestie, keep it exact. ⏳

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so the process is put to sleep (TASK_INTERRUPTIBLE) until condition evaluates to true or a signal is received. The condition is checked each time the waitqueue wq_head is woken up. It's giving "nap, but make it event-driven." 😴✨

wake_up has to be called after changing any variable that could change the result of the wait condition. This is not optional, fr fr. Like, if you change the thing and don't wake it up, that's not slay behavior. 🚨

This is supposed to be called while holding the lock. The lock is dropped before going to sleep and is reacquired afterwards. So it's lowkey a trust fall with the lock β€” except the kernel is the one catching you. 🫢

Return-value tea, and it's important:

  • 0 if the timeout elapsed.
  • -ERESTARTSYS if it was interrupted by a signal.
  • the remaining jiffies otherwise, if the condition evaluated to true before the timeout elapsed.

That's the whole return vibe check. Slay, now you know what you're getting back. πŸ’œ


πŸ‘€ SEE ALSO πŸ‘€

Kernel file: ./include/linux/wait.h β€” and the whole waitqueue squad is here, no gatekeeping:


Byeee bestie πŸ’– β€” source: ./include/linux, date: October 2026, page: wait_event_..._irq_timeout(9). πŸŽ€

πŸ“¦ where this page comes from