WORKQUEUE(9)

🌸 NAME 🌸

okay so this is workqueue(9) from the Kernel Developer's Manual, and the whole vibe is simple do-it-in-thread-context framework. like, it's the little setup that lets you shove work off to a thread instead of doing it right this second. bestie, it's giving "I'll handle it in thread context" energy, and honestly? iconic. 💅✨

---

✨ SYNOPSIS ✨

#include <sys/workqueue.h>

int
workqueue_create(struct workqueue **wqp, const char *name,
    void (*func)(struct work *, void *), void *arg, pri_t prio, int ipl,
    int flags);

void
workqueue_enqueue(struct workqueue *wq, struct work *wk,
    struct cpu_info *ci);

void
workqueue_wait(struct workqueue *wq, struct work *wk);

void
workqueue_destroy(struct workqueue *wq);

---

💖 DESCRIPTION 💖

the workqueue utility routines are here to defer work that needs to be processed in a thread context. no cap. like, you don't do it inline — you hand it to the workqueue framework and it gets handled by a worker thread. periodt. ✨🫶

🎀 workqueue_create() 🎀

workqueue_create() creates a workqueue. it takes these arguments, bestie:

• wqp — where to store the created workqueue. like, that's the spot it gets filled into. 🫶
• name — the name of the workqueue. label it cute so you know what it is.
• func — the function to be called for each work. this is the callback that does the actual thing.
• arg — an argument to be passed as the second argument of func. literally that.
• prio — the priority level for the worker threads.
• ipl — the highest IPL at which this workqueue is used. highkey important.
• flags — the value 0 indicates a standard create operation, but you can bitwise OR these flags together:
  • WQ_FPU — specifies that the kthread must be allowed to use any machine-dependent per-CPU floating-point units or SIMD vector units, as in kthread_fpu_enter(9) / kthread_fpu_exit(9), when it executes the worker function. like, FPU/SIMD permission slip activated. 🔥
  • WQ_MPSAFE — specifies that the workqueue is multiprocessor safe and does its own locking; otherwise the kernel lock will be held while processing work. so either it locks itself or the kernel lock is held — no in-between. 💀
  • WQ_PERCPU — specifies that the workqueue should have a separate queue for each CPU, thus the work could be enqueued on concrete CPUs. one queue per CPU, slay. 👑

🌈 workqueue_enqueue() 🌈

workqueue_enqueue() enqueues the work wk into the workqueue wq. simple. ✨

if the WQ_PERCPU flag was set on workqueue creation, the ci argument may be used to specify the CPU on which the work should be enqueued. also it may be NULL, and then work will be enqueued on the current CPU. if the WQ_PERCPU flag was not set, ci must be NULL. okay? don't play with it. 🙈

the enqueued work will be processed in a thread context. and a work must not be enqueued again until the callback is called by the workqueue framework. that's a hard rule, bestie — no double-enqueue. 😭

🦋 workqueue_wait() 🦋

workqueue_wait() waits for a specified work wk on the workqueue wq to finish. it's literally "wait for this one to be done". the caller must ensure that wk will not be enqueued to the workqueue again until after workqueue_wait() returns. so no sneaky re-enqueue while waiting. periodt. ✋💅

🧚 workqueue_destroy() 🧚

workqueue_destroy() destroys a workqueue and frees associated resources. the caller should ensure that the workqueue has no work enqueued beforehand. like, clean it out first — don't just nuke it with pending work. that's the vibe check. 🫶🌸

---

🔥 RETURN VALUES 🔥

workqueue_create() returns 0 on success. otherwise, it returns an errno(2). so if it's not 0, check your errno, bestie. fr fr. 💅

---

🦋 CODE REFERENCES 🦋

the workqueue subsystem is implemented within the file sys/kern/subr_workqueue.c. that's where the magic lives. ✨

---

🎀 SEE ALSO 🎀

• callout(9)
• condvar(9)
• kthread(9)
• softint(9)

---

okay that's the whole page, mwah 💋 — this Debian footer says December 28, 2017 and WORKQUEUE(9), so that's the source/version and date, and I'm obsessed with how clean that is. 🌸👑