This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17214] Expose a clone variant that shares stacks instead of jumping to a new one
- From: "sstewartgallus00 at mylangara dot bc.ca" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 19 Dec 2014 20:29:16 +0000
- Subject: [Bug nptl/17214] Expose a clone variant that shares stacks instead of jumping to a new one
- Auto-submitted: auto-generated
- References: <bug-17214-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17214
--- Comment #13 from Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc.ca> ---
I am well aware of many of the problems of vfork. You are right that a huge
problem is that it doesn't work well with certain compiler optimizations (such
as done by Clang in particular). I suppose I really should just use vfork with
a new stack and avoid one problem of it (although I'm not sure that works as
vfork sets all memory except the current stack as read only in the process,
maybe some hack where the function would need to jump to the new stack, vfork
and then jump back in the child would be needed). As well, I would definitely
prefer using posix_spawn over vfork but unfortunately I can't for a few use
cases (also the current GLibc implementation of posix_spawn doesn't use the
pipe trick to report errors). Also, vfork wasn't eliminated at all and is still
around for very good reasons.
--
You are receiving this mail because:
You are on the CC list for the bug.