> Yeah, I checked that out. The one difference here is that that was a
The essence that matters is the same: something that current does with its
own ->signal on a tick vs something that the release_task path does.
Tomato, tomato. You're adding new data structures and lifetime rules to
replace data that was described in a different data structure before, yet
your new data's meaningful semantic lifetime exactly matches that of
signal_struct. You could as well make everything release_task cleans up be
done in __put_task_struct instead, but that would not be a good idea
either. You've added a word to task_struct (100000 words per 100000-thread
process, vs one word). It's just not warranted.
With the perspective of tunnel vision to just your one test case, adding
something entirely new considering only that case always seems simplest.
That's not how we keep the entire system from getting the wrong kinds of
complexity.
No. current->exit_state can go from zero to nonzero only by current
running code in the do_exit path. current does not progress on that
path while current is inside one update_process_times call.
Thanks,
Roland
--
