[M3devel] removing vfork, general header cloning matters?

[Jay K]

I say we remove vfork from m3core.

 

 

 - We never use it in cm3. To be confirmed.

 

 - It cannot be portably wrapped in C without

    violating Posix. And is that theoretical or real?

    Posix says you can't return from the caller of vfork.

    It must exec or _exit.

    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.

    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.

 

 - It doesn't have a portable name.

   Witness netbsd2-i386/Unix.i3.

   I assume that is correct or close?

   But maybe this is an "ideal" vs. "possible, works" case? (see below)

 

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

 

Unless it can be shown that the NetBSD example is wrong, or unnecessary?

I'm a little torn. In particular, "header cloning", despite my distaste, is not unique to Modula-3.

And there is some good chance that the names are actually portable.

You know, it might be more efficient on Linux to #include <sys/stat.h> and get all the

stat wrappers, the static libraries probably contain them in the "normal" way.

If I get back to NetBSD and find they are compatible this way too, then maybe the current form is ok.

 

You know, the question is..while types and constants are definitely an issue and reasonably

dealt with, "function names" maybe aren't?

 

 

Note that vfork doesn't really merit this level of discussion but I'd like to understand the general case.

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?)

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091105/e6bab217/attachment-0001.html>