[M3devel] removing vfork, general header cloning matters?

Mike Frysinger vapier at gentoo.org
Thu Nov 5 20:19:47 CET 2009


On Thursday 05 November 2009 12:35:47 Jay K wrote:
> I say we remove vfork from m3core.
> 
>  - It cannot be portably wrapped in C without
>     violating Posix. And is that theoretical or real?

i dont know what "wrapped" means, but vfork is no longer in POSIX.  it was in 
older specs, but it has been dropped.

>     Posix says you can't return from the caller of vfork.
>     It must exec or _exit.

POSIX does not say this.  it says that behavior is undefined if the child of 
vfork() does anything other than exec or _exit.  "undefined" means 
implementers are allowed to do anything they want otherwise (including crash).

in reality, there is a lot you can actually do, but returning from the 
function that called vfork() is not one of them.  in doing so, you most often 
modify the stack, and once the child does exit/whatever, the parent will see 
the mangled stack state and often crash & burn.

>     It'd be cool if we could have a jump or tail recursion
>      but that's probably not feasible.
>     Maybe a function pointer?? I can try that out.

in practice, you can call as many functions after vfork() as you like.  
ultimately, the child needs to call exec or _exit, else the parent stays 
frozen indefinitely.

>     Would have to see if Posix allows vfork to be a macro through.
>     We could declare a function pointer and then the C implementation
>     could have an #ifdef around it -- not provide the function pointer on
>  all platforms.

POSIX doesnt care about how vfork() is implemented -- prototype or a define 
that expands.  i dont really see the point though.

> IF we ever get to a system where vfork is advantagous against fork, uses
>  should be written in C.

doing vfork;exec is pretty much always a win over fork;exec.  the question 
comes down to how much of a win and whether it's worth the hassle.

> Maybe I just need to read more of the Posix spec and maybe it talks about
>  link level naming vs. C source level constructs? Ie. maybe they talk about
>  Ada, Pascal, etc. bindings?? (ie: maybe people really do support languages
>  other than C via acceptable header cloning?)

i'm pretty sure POSIX doesnt dictate the link level names, only the C API.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091105/21bf227e/attachment-0002.sig>


More information about the M3devel mailing list