cvs commit: src/sys/kern kern_exit.c kern_thread.c

[David Xu]

On Thursday 16 March 2006 21:34, John Baldwin wrote:
> I'm not sure why setrunqueue() of some other thread X != curthread
> would care about the state of curthread since it should bail out of
> preemption checking as soon as it sees that curthread is in a critical
> section.
> 
The problem is that you have unregistered current thread from scheduler,
but still call setrunqueue, this may cause lots of scheduler code to be 
involved in, AFAIK, it is the deepest code path in both schedulers,
whether it works or not is totally dependent on how a scheduler is
designed, it may or may not have interesting to check current thread's
attributes. at least, I would like to avoid such risk.

> In any case, you can always move the function call in question down
> further below the proc unlock.  One change I had in my patches was
> to stick the PROC_UNLOCK() after the big if-statement so there was
> just one of them instead of doing it at the end of each case in the
> if-else.
> 
This branch code was written by julian, I don't have any idea whether it is 
good or bad, but I can understand that he might had prepared to handle 
different cases, but simply there was nothing to do in else case, I really 
don't care this style, some books even suggest programmer to always write 
a else branch for if statement. :-)

David Xu