Fork improvements

[ChrisJefferson]

This PR adds SyFork, a wrapper around for which allows functions to be called pre- and post- fork. Profiling then uses this to create a new profile output for each child, to avoid the profile output getting corrupted.

If/when this is merged, I will force the IO package to use SyFork (when it is available), so forks which happen in IO can also be tracked.

[fingolfin]

I think the use of vfork here is/was meant as an optimization that preserves memory and is also easier to implement on, say, Windows, than full fork. This PR silently changes it to fork, a deoptimization. Do we really want that? Perhaps a SyVFork is needed, too?

[ChrisJefferson]

The spec for vfork says the only functions you are allowed to call after a vfork is _exit or exec*. We are calling chdir, open, fcntl and SyBufFileno (which is one of our functions, but I believe even that isn't acceptable). I can't find any spec that says that's acceptable, even on Linux. However, I shouldn't have bundled this into the same PR, as if we want to keep vfork a SyVfork would be easy to add.

[ChrisJefferson]

Actually, cygwin's vfork just calls fork it turns out (from some mailing list reading), although I think linux vfork actually does "proper" vfork.

[fingolfin]

So, when adding documentation comments, I'd either make them match the existing ones, or radically different; but this is kind of a mishmash (only one space after **, no empty line after the *F line, no start line with /*****.

If you don't mind, I can amend this PR accordingly.

[ChrisJefferson]

I'm happy to adjust it. I want to look at why hpc-gap is crashing (I suspect switching vfork for fork, which suprises me, as I expected that to make hpc-gap more stable, not less.

[ChrisJefferson]

Oh, I also removed a use of vfork, as we are using vfork in a very inapproriate way (I'm assuming on modern OSes vfork and fork must be equivalent, as by the book our use of vfork shouldn't be legal I believe).

[ChrisJefferson]

I've realised, on further use, that this PR is actually not really want I wanted at the moment. I think I want to distinguish in the child between:

• This child GAP will continue to exist as a GAP (so the profiler has to care)
• This child will exec immediately, so there is no point making the profiler open a new file (it should still close the existing file, so the new execed process doesn't abuse it).

[ChrisJefferson]

closing because this was a stupid idea. Sorry.