[M3devel] removing vfork, general header cloning matters?

[Jay K]

Mike, thank you for the detailed response.

 

 

"not wrapped (in C)" is:

 


foo.i3
INTERFACE IFoo;
<*external*>
PROCEDURE Foo();

 

END IFoo.

 

cm3 generates reference to "Foo".


"wrapped (in C) is:

 

foo.i3


INTERFACE IFoo;


<*external IFoo__Foo*>
PROCEDURE Foo();

 

END IFoo.

 

cm3 generates reference to IFoo__Foo.

 

foo.c

 

#include whatever.h

void IFoo__Foo()
{
 Foo();
}

 

 

To the extent that whatever.h is simply:

 

void Foo(void);

 

it doesn't matter.

 

To the extent that whatever.h is

 

inline void Foo(void) { ..stuff.. }

 

or


#define Foo Fooabcdef

void Foo(void);

 

 

or such AND that compatibility isn't provided for simply void Foo(void);
wrapping is required. Or adapting the .i3 somehow, not portably.


 

Wrapping is generally easy and safe and portable and wards of any such problems.
Slightly wasteful, granted.


 

However because the caller of vfork is undefined if it returns
and often bad in practise (adopting/agreeing with what you say)
this wrapping is not a good direction, for this particular function.
Therefore stuck between contradictions.

 

 

fork/exec vs. vfork/exec
On current systems why does vfork ever win?
Or win significantly?

 


If it is a significant win, we can/should rewrite our fork use in C.
(not necessarily the entire function, just the part up to exec/_exit).

 


Even though vfork is no longer Posix, it is still widespread with matching semantics everywhere?
Always either equivalent or slightly faster?

 


The disappointing thing is that the system with the really really slow fork -- Cygwin -- has an identical vfork.

 

Thanks,

 - Jay

 
> From: vapier at gentoo.org
> To: m3devel at elegosoft.com
> Date: Thu, 5 Nov 2009 15:19:47 -0400
> CC: jay.krell at cornell.edu
> Subject: Re: [M3devel] removing vfork, general header cloning matters?
> 
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091105/a46257a6/attachment-0002.html>