Allow HPC-GAP to run as a forkable server process.

[rbehrends]

This change is prompted by trying to make HPC-GAP work for Jupyter. Note that it changes the meaning of the -S command line option and therefore is labeled as WIP. I've put up the pull request so that people can test the functionality of Jupyter + HPC-GAP, even if details still needs to be settled. Note also that so far I've only tested this on macOS.

This commit includes the following changes:

1. The Boehm GC is configured to properly handle fork().
2. The -S command line option now starts HPC-GAP up in single-threaded
   mode without any other threads running.
3. Normally, signals are handled by a separate thread; this is now being
   done in the function InstallHPCGAPSignalHandling. If started with
   -S, this function needs to be called explicitly in order to enable
   proper handling of SIGINT etc.

Please use the following template to submit a pull request, filling
in at least the "Text for release notes" and/or "Further details".
Thank You!

[olexandr-konovalov]

Thanks @rbehrends - this seems to work, we will do some further testing now.

[rbehrends]

The one thing that I'm not happy with (yet) is that this basically requires starting the signal handler thread manually if run with -S. I'm thinking that maybe we need two different options to distinguish between "batch mode" and "server mode" ways of running without the console UI.

[olexandr-konovalov]

@rbehrends maybe new command line option (-J for Jupyter?)

[coveralls]

Coverage increased (+7.0e-05%) to 84.506% when pulling 2d354dd on rbehrends:hpcgap-server into ba30bd4 on gap-system:master.

[rbehrends]

Something like this is what I'm thinking, except that this is only going to be used programmatically, so we don't have to waste a single letter command line option on it. Something like --single-thread or --server-mode?

[olexandr-konovalov]

@rbehrends let's spare a single-letter option indeed, but both --single-thread or --server-mode could be equally confusing (e.g. understood as ways to disable threading completely, or to run an SCSCP server). What about --jupyter-mode? This will also be reusable outside HPC-GAP if we will discover that we need it later e.g. in GAP 4.12.

[rbehrends]

The thing is that it's not really "Jupyter mode". What it does is it making sure that GAP starts up with only a single thread running. This is more of a fork-compatible mode. Jupyter is just one application for that.

[olexandr-konovalov]

I see. And who knows, maybe for SCSCP package it will be useful as well. Anyhow, it serves the purpose for now, and we can use it next week, and think about a good option name in the meantime. Thanks again!

[rbehrends]

I've added a --single-thread option and reverted the semantics of -S; the name is a placeholder for now, but with the logic in place, it can easily be renamed.

[olexandr-konovalov]

@rbehrends thanks - then we will update our setup for Jupyter notebooks HPC-GAP demo.

[fingolfin]

In the PR description, you write that you changed the behavior of -S, but that doesn't really seem to be the case?

[rbehrends]

@fingolfin See my comment above. I reverted the changes to -S in a later commit and introduced a separate command line option. I'll fix the formatting later tonight.

[fingolfin]

This actually looks good to me. Why exactly is this marked as WIP? Because the name of that command line option might be changed? Any other reason?

If @alex-konovalov and @stevelinton and @ChrisJefferson are happy with this PR, I am also happy to have it merged :-)

[rbehrends]

Yeah, it's WIP because I basically just made up a name for the command line option and wanted to first check that this is fine with everyone.

[rbehrends]

Also, another thing with --single-thread is that if you want signal handling, you need to do that after startup/forking by calling InstallHPCGAPSignalHandling(). This is currently not documented, nor is it clear whether we want that name or a more generic name like FinishHPCStartup() if we later need to put additional functionality in there.

[olexandr-konovalov]

@rbehrends shall we merge this?

[rbehrends]

If it's okay this way, I'll squash the commits, update the commit message, and then we can, yes.

[rbehrends]

Update: I've squashed the commits as noted above, if the tests work, it can be merged.

[olexandr-konovalov]

@rbehrends thanks!

[fingolfin]

Shall this be backported to 4.11?

[olexandr-konovalov]

@fingolfin I think so!

[fingolfin]

Backported to stable-4.11 in commit ac4b898