RE: Change signal mask after vfork/clone system call

[Gregory Giguashvili]

Any comments on this issue? If you think this mailing list is not appropriate for submitting such questions, I would appreciate a pointer to the one that is.
To me, it seems to be related to "clone" system call functionality and flexibility.

Thanks
Giga

-----Original Message-----
From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Gregory Giguashvili
Sent: Tuesday, October 19, 2010 9:54 AM
To: linux-kernel@xxxxxxxxxxxxxxx
Subject: Change signal mask after vfork/clone system call

For new processes created by vfork, while signals are blocked using pthread_sigmask: is there a way in a multi-threaded parent to safely unblock signals before the new process is started? Does pthread_atfork like functionality exist for vfork-ed processes maybe?

Ideally, the following code should work, except we're not allowed to call anything in the child process besides exec family of functions.

sigmask_t new;
sigmask_t old;
sigaddset (&new, SIGCHLD);
pthread_sigmask (SIG_BLOCK, &new, &old);

switch (vfork ()) {
case 0: // parent
	break;
case -1: // error
	break;
default: // child
	pthread_sigmask (SIG_SETMASK, &old, NULL);
	execv (...);
	_exit (-1);
}

Finally, if using fork should be efficient for starting processes from applications with heavy VM/RSS memory footprint, this question becomes obsolete.

Thanks
Giga

---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/