[M3devel] fork/vfork

[Jay K]

so..in the area of not cloning C headers..fork/vfork has been a lingering still cloned thing.
It was already bothering me.


I was going to make fork a function pointer at least, so it could honor any #defines or renaming via target specific #pragmas.
That way as well we could also go back to vfork where it is a /little/ faster.


Fork and/or vfork are not portably wrappable in the usual way because the caller of one or both of them
cannot return without calling _exit or an exec function.
A wrapper would violate this.
I believe I had this violation in temporarily and I believe it did cause a problem.


But now there is a bigger problem:


VMS:

#if defined(__ALPHA)
    __int64_ptr32 decc$$get_vfork_jmpbuf(void);
    int LIB$GET_CURRENT_INVO_CONTEXT(__int64 *__invo_context);
    int decc$$alloc_vfork_blocks(void);

#   define vfork() (decc$$alloc_vfork_blocks()>= 0 ? \
    LIB$GET_CURRENT_INVO_CONTEXT(decc$$get_vfork_jmpbuf()) : -1)


which further motivates "rewriting" vfork users in C.
There are only about two of them.


I intend to look into and do this unless there is strong protest.


vfork is implemented with a trick that is also mentioned in some Cygwin documentation,
something Cygwin attempted but doesn't do.
vfork calls setjmp.
It returns -1 so the caller thinks it is in the child process.
exec calls longjmp, returning the pid on the second return to the parent.
Something like that.


I almost wonder if we can do this ourselves.


But not calling fork/vfork from Modula-3 directly was already a good idea.
Now even better.


We can leave in fork/vfork external declarations and folks that don't care to run on VMS can still call them.
 (and convert them to function pointers as per my previous thinking)


 - Jay