On Fri, Nov 22, 2024 at 08:43:33PM +0100, Alice Ryhl wrote: > On Fri, Nov 22, 2024 at 8:30 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Fri, Nov 22, 2024 at 11:17:15AM -0800, Boqun Feng wrote: > > > > I don't think this is a problem? As long as a thread exists somewhere > > > > with `current` being equal to the task, we should be fine? > > > > > > > > > > I think I had a misunderstanding on what you meant by "operations > > > that are only valid on the current task", you mean these operations can > > > be run by other threads, but it has to be *on* a task_struct that's > > > "currently running", right? BTW, you probably want to reword a bit, > > > because the "current" task may be blocked, so technically it's not > > > "running". > > > > > > Basically, the operations that `CurrentTask` have are the methods that > > > are safe to call (even on a different thread) for the "current" task, as > > > long as it exists (not dead or exited). In that definition, not being > > > `Sync` is fine. > > > > > > But I have to admit I'm a bit worried that people may be confused, and > > > add new methods that can be only run by the current thread in the > > > future. > > > > I agree, I think CurrentTask should refer to "current". Or we'll > > confuse everyone. Would ActiveTask be a good name for this CurrentTask? > > I mean, it does refer to current. Any time you have a `&CurrentTask`, > then you know that you got the pointer by reading the value of > `current`, and that the task you got it from hasn't returned to > userspace (or otherwise exited) yet. > > But the name ActiveTask also makes sense I guess. OK, I'm going to be all rust newbie about this (zoea?) Given that there are operations that we can do on 'current' that aren't safe to do if we pass current to another thread, is the right thing to say that we have Task, and you can get a (Rust) reference to Task either by it being 'current', or by getting a refcount on it using get_task_struct()? And I think that's called a typestate?
