On Sun, Dec 15, 2013 at 15:57, Philip Guenther wrote:
> On Sat, Dec 14, 2013 at 10:34 AM, Ted Unangst <t...@tedunangst.com> wrote:
>> On Fri, Dec 13, 2013 at 19:42, Philip Guenther wrote:
>>> +static __inline int
>>> +process_is_multithreaded(struct process *pr)
>>> +{
>>> + struct proc *p = TAILQ_FIRST(&pr->ps_threads);
>>> + return (p != NULL && TAILQ_NEXT(p, p_thr_link) != NULL);
>>
>> This list will never be empty, so you can drop the p != null check.
>
> Umm, no. The last thread in the process removes itself from the
> process's thread list fairly early in exit1(), and the continues to do
> all sorts of stuff, calling piles of code. My larger diff calls this
> function in the PCATCH bits of tsleep()...and without the NULL check
> the kernel paniced with a back trace from exit1() through fdfree() and
> down through to ttyclose() and somewhere under there it calls
> tsleep(PCATCH).
I am concerned then that this function will lie. Or at least, the
precise specification for it escapes me. This will return false for a
process that was threaded, but isn't anymore, which seems ok, but
fuzzy in the case where only a spawned thread and not the main thread
is left. The case where the only remaining thread is not the main
thread is something that may need to be handled either as threaded or
not threaded. I'm a little worried that an abstraction like this will
lead to mistakes if the definition isn't clear.
