svn commit: r222060 - in user/avg/xcpu/sys: kern sys

[Andriy Gapon]

on 18/05/2011 23:06 Attilio Rao said the following:
> However I think that TDF_INPANIC handling is not optimal.
> You should really acquire thread_lock otherwise you are going to break
> choosethread() concurrency.
> 
> I would prefer to make TDF_INPANIC a private flag and just use it with
> curthread, if possible, but I still don't have a good way to resolve
> choosethread() (I would dig the runqueue adding path and resolve the
> problem later in the codeflow, I think).

I've been thinking about this.
I think that in the new world where only one thread runs after panic we could just
reduce TD_IS_INPANIC to panicstr != NULL, TDF_INPANIC could be removed altogether
along with the check in  choosethread().  But for some initial period I would like
to have an option to disable CPU stopping (to protect from possible bugs,
regressions, etc) and for that I would like to keep TDF_INPANIC.  The flag could
be set without thread_lock() because we still allow only one thread to be in/after
panic.  But I completely agree with you that it is cleaner to move TDF_INPANIC to
private flags.

So the first step:
TDF_INPANIC => to private flags

Some time in the future:
TDF_INPANIC => removed
TD_IS_INPANIC => panicstr != NULL

-- 
Andriy Gapon