<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Mike, thank you for the detailed response.<BR>
<BR>
<BR>
"not wrapped (in C)" is:<BR>
<BR>
<BR>foo.i3<BR>INTERFACE IFoo;<BR><*external*><BR>PROCEDURE Foo();<BR>
<BR>
END IFoo.<BR>
<BR>
cm3 generates reference to "Foo".<BR>
<BR>"wrapped (in C) is:<BR>
<BR>
foo.i3<BR><BR>
INTERFACE IFoo;<BR><BR>
<*external IFoo__Foo*><BR>PROCEDURE Foo();<BR>
<BR>
END IFoo.<BR>
<BR>
cm3 generates reference to IFoo__Foo.<BR>
<BR>
foo.c<BR>
<BR>
#include whatever.h<BR>
void IFoo__Foo()<BR>{<BR> Foo();<BR>}<BR>
<BR>
<BR>
To the extent that whatever.h is simply:<BR>
<BR>
void Foo(void);<BR>
<BR>
it doesn't matter.<BR>
<BR>
To the extent that whatever.h is<BR>
<BR>
inline void Foo(void) { ..stuff.. }<BR>
<BR>
or<BR><BR>
#define Foo Fooabcdef<BR>
void Foo(void);<BR>
<BR>
<BR>
or such AND that compatibility isn't provided for simply void Foo(void);<BR>wrapping is required. Or adapting the .i3 somehow, not portably.<BR>
<BR> <BR>
Wrapping is generally easy and safe and portable and wards of any such problems.<BR>Slightly wasteful, granted.<BR>
<BR> <BR>
However because the caller of vfork is undefined if it returns<BR>and often bad in practise (adopting/agreeing with what you say)<BR>this wrapping is not a good direction, for this particular function.<BR>Therefore stuck between contradictions.<BR>
<BR>
<BR>
fork/exec vs. vfork/exec<BR>On current systems why does vfork ever win?<BR>Or win significantly?<BR>
<BR>
<BR>If it is a significant win, we can/should rewrite our fork use in C.<BR>(not necessarily the entire function, just the part up to exec/_exit).<BR>
<BR>
<BR>Even though vfork is no longer Posix, it is still widespread with matching semantics everywhere?<BR>Always either equivalent or slightly faster?<BR>
<BR>
<BR>The disappointing thing is that the system with the really really slow fork -- Cygwin -- has an identical vfork.<BR>
<BR>
Thanks,<BR>
- Jay<BR><BR> <BR>> From: vapier@gentoo.org<BR>> To: m3devel@elegosoft.com<BR>> Date: Thu, 5 Nov 2009 15:19:47 -0400<BR>> CC: jay.krell@cornell.edu<BR>> Subject: Re: [M3devel] removing vfork, general header cloning matters?<BR>> <BR>> On Thursday 05 November 2009 12:35:47 Jay K wrote:<BR>> > I say we remove vfork from m3core.<BR>> > <BR>> > - It cannot be portably wrapped in C without<BR>> > violating Posix. And is that theoretical or real?<BR>> <BR>> i dont know what "wrapped" means, but vfork is no longer in POSIX. it was in <BR>> older specs, but it has been dropped.<BR>> <BR>> > Posix says you can't return from the caller of vfork.<BR>> > It must exec or _exit.<BR>> <BR>> POSIX does not say this. it says that behavior is undefined if the child of <BR>> vfork() does anything other than exec or _exit. "undefined" means <BR>> implementers are allowed to do anything they want otherwise (including crash).<BR>> <BR>> in reality, there is a lot you can actually do, but returning from the <BR>> function that called vfork() is not one of them. in doing so, you most often <BR>> modify the stack, and once the child does exit/whatever, the parent will see <BR>> the mangled stack state and often crash & burn.<BR>> <BR>> > It'd be cool if we could have a jump or tail recursion<BR>> > but that's probably not feasible.<BR>> > Maybe a function pointer?? I can try that out.<BR>> <BR>> in practice, you can call as many functions after vfork() as you like. <BR>> ultimately, the child needs to call exec or _exit, else the parent stays <BR>> frozen indefinitely.<BR>> <BR>> > Would have to see if Posix allows vfork to be a macro through.<BR>> > We could declare a function pointer and then the C implementation<BR>> > could have an #ifdef around it -- not provide the function pointer on<BR>> > all platforms.<BR>> <BR>> POSIX doesnt care about how vfork() is implemented -- prototype or a define <BR>> that expands. i dont really see the point though.<BR>> <BR>> > IF we ever get to a system where vfork is advantagous against fork, uses<BR>> > should be written in C.<BR>> <BR>> doing vfork;exec is pretty much always a win over fork;exec. the question <BR>> comes down to how much of a win and whether it's worth the hassle.<BR>> <BR>> > Maybe I just need to read more of the Posix spec and maybe it talks about<BR>> > link level naming vs. C source level constructs? Ie. maybe they talk about<BR>> > Ada, Pascal, etc. bindings?? (ie: maybe people really do support languages<BR>> > other than C via acceptable header cloning?)<BR>> <BR>> i'm pretty sure POSIX doesnt dictate the link level names, only the C API.<BR>> -mike<BR> </body>
</html>