Messages in this thread | | | From | "Eric W. Biederman" <> | Date | Mon, 17 Jan 2022 09:45:30 -0600 | Subject | Re: [GIT PULL] signal/exit/ptrace changes for v5.17 |
| |
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Jan 17, 2022 at 6:08 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> >> >> People sometimes think that is just a "poll/select()" thing, but >> that's not at all true. It's quite valid to do things like >> >> add_wait_queue(..) >> for (.. some loop ..) { >> set_current_state(TASK_INTERRUPTIBLE); >> ... do various things, checking state etc .. >> schedule(); >> } >> set_current_state(TASK_RUNNABLE); >> remove_wait_queue(); > > Of course, in most modern cases, the above sequence is actually > encoded as a "wait_event_interruptible()", because we don't generally > want to open-code the whole thing.
Yes.
What I was looking at that inspired the question is that "wake_up" ultimately expands to "try_to_wake_up(task, TASK_NORMAL, 0)".
Whereas "wake_up_interruptible" expands to "try_to_wake_up(task, TASK_INTERRUPTIBLE, 0)".
With the practical challenge that if I want to change wait_event_interruptible to wait_event_killable I need to change all of the wakers.
> But the actual end result still ends up being exactly the same, it's > just syntactically denser and more legible version of the above thing, > and you can still have the "event" you wait on have nested waiting > situations. > > The nested waiting is by no means common. The only _common_situation > where you're on multiple wait queues tends to be select/poll kind of > things, when they aren't really nested as much as iterated over, but > conceptually the nested case is still quite important, and it allows > you to do things that a traditional "wait_on()" interface with just > one single wait-queue just doesn't allow for.
I think it may just be the part of the kernel where I usually work. Changing wait_event_interruptible to wait_event_killable has always just worked for me, but it doesn't in the pipe code.
It doesn't because of wake_up_interruptible.
I do know that short-term-disk-sleep aka task_uninterruptible is special to performing things like disk I/O, and really short term things.
It might just be the names but I look at wake_up_interruptible and my klaxon's go off in my head saying something doesn't make sense. So I will read up and look at those nested wait-queue scenarios and see if I can find the piece of understanding I am missing.
Eric
| |