Messages in this thread | | | From | (Alan Cox) | Subject | Re: Porting vfork() | Date | Thu, 7 Jan 1999 23:06:14 +0000 (GMT) |
| |
> My intent in this thread was to gage the vfork() impact. It makes no sense > to commit time developing a kernel solution if only a very few applications > have such silly dependencies.
I think you can fix it in libc. Make vfork() do a clone with CLONE_VM and leave a small gap in the stack for the parent to use.
In the client we run as before. The parent waits on a pthread mutex of some sort which libc can clean up on exit, or exec (I belive those are the right cases ?). I guess it needs to block all signals too.
So in theory its doable in glibc if anyone is feeling extremely clever
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |