Messages in this thread | | | Date | Fri, 11 Nov 2011 20:55:45 +0400 | From | Pavel Emelyanov <> | Subject | Re: [PATCH 3/3] pids: Make it possible to clone tasks with given pids |
| |
>> This will make it impossible to fork() children on restore in parallel. And >> I don't want to lose this ability :( > > Yes, this is true. You need some form of synchronization in user-space. > But, otoh, prctl/sysctl/whatever is much simpler. Both from implementation > pov and from understanding/using. You can even do, say, pthread_create() > to make a thread with the desired tid. And of course I like the fact we > do not add the new hacks into copy_process's paths. > > And. If you want to restore the process tree, then these new children > have to cooperate anyway. Say, nobody can clone() without > CLONE_CHILD_USEPIDS before we restore all pids. > > Yes, sysctl+clone should be "atomic", but that is all. Does it really > hurt? OK, if nothing else, can't you do somthing like > > int fork_with_pid(int pid) > { > int ret; > int pipefd[2]; > > pipe(pipefd); > > retry: > prcrl(PR_SET_LAST_PID, pid-1); > ret = fork(); > > if (ret == 0) { > /* child, wait from parent's ACK */ > read(pipefd[0], 1, NULL); > return 0; > } > > /* raced with another user of PR_SET_LAST_PID */ > if (unlikely(ret != pid) { > kill(ret, SIGKILL); > waitpid(ret); > goto retry; > } > > close(pipefd[1]); > return pid; > } > > ?
Nope, as I said to Tejun, we will most likely not forks children in the depth-first order, since tasks can share resources and we'll have to calculate the necessary fork order. Thus this simple interaction simply won't work, more complexity will be required.
But I don't insist. If the CLONE_CHILD_USEPIDS has absolutely no way in the kernel we'll have to go the uglier path.
> Oleg.
| |