Yes, I am using TIOCNOTTY ioctl instead.And I really think there is no otherDepends on what "daemonize" means. Even with this patch, setsid()
way to daemonize the process with threads, than to use something
like this patch, or is there?
after PR_DETACH can fail because we do not change the pids and
the caller can still be pgrp leader.
And. What if the parent of PR_DETACH caller blocks or ignoresI am currently rewriting the patch to solve this all.
SIGCHLD or simply doesn't call do_wait()? The caller can run with
PR_DETACH set without any effect "forever".
So, to be honest, I do not think this idea will be accepted, and I don'tLets see if the clean implementation is possible first. :)
really understand your motivation. But once again, I never argue with the
"we need this feature" requests, no need to convince me.
The problem is that ptrace uses this ->exit_code member as well.Also do_signal_stop() seems to alter it.
Suppose that the (ptraced) task calls PR_DETACH and, say, recieves
a signal after that. See ptrace_signal().
I understand why you added PF_EXITING. And, once again, this is notOK, I'll address also this.
right afaics. The current condition is more or less "random" and mostly
historical, although correct. If we want to take PF_EXITING into account,
we should just add BUG_ON(!(tsk->flags& PF_EXITING)). IOW, it is just
wrong to call this function unless this tsk exits.