new approach to calling fork(2) in remote Lisp images

Drop CAN-PROBABLY-FORK because we now only try to fork(2) in contexts in which
there shouldn't ever be any other threads running, apart from Lisp
implementation finaliser threads and the like.

We no longer need to RESET-DATA-SOURCES before CONTINUE-DEPLOY* because we now
only fork(2) in contexts in which *NO-DATA-SOURCES* is t.

Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>

2 files changed, 17 insertions, 21 deletions

diff --git a/doc/connections.rst b/doc/connections.rst
index 58b8dfe..cbb1597 100644
--- a/doc/connections.rst
+++ b/doc/connections.rst
@@ -112,22 +112,17 @@ in that saved image.  Typically a ``:SUDO`` connection hop is used before hops
 which start up remote Lisp images, so these issues will not arise for most
 users.
 
-``:CHROOT.FORK``
-~~~~~~~~~~~~~~~~
-
-Since forking is typically only possible when it is not the case that multiple
-threads are running, it is better to avoid using this connection type as the
-first hop, i.e., directly out of the root Lisp (this is not much of a
-restriction, since typically the root Lisp is running under a uid which cannot
-use the ``chroot(2)`` system call anyway).  More generally, you should avoid
-using this connection type within a Lisp image which might try to execute
-other deployments in parallel.  Typical usage would be something like::
+Connections which fork: ``:CHROOT.FORK``, ``:SETUID``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These connection types cannot be used as the first hop, i.e., directly out of
+the root Lisp.  This is because they must call fork(2), and Consfigurator only
+makes this system call in contexts in which there shouldn't ever be more than
+one thread (excluding Lisp implementation finaliser threads and the like).
+The root Lisp is not such a context, because it is often multithreaded due to
+the use of SLIME.  This is, however, not much of a restriction, because
+typically the root Lisp is running under a UID which cannot use system calls
+like chroot(2) and setuid(2) anyway.  Thus, typical usage on localhost would
+be something like::
 
   (deploy (:sudo :sbcl (:chroot.fork :into "...")) ...)
-
-In some situations you might want to have a connection chain which effectively
-uses a connection type like ``:SBCL`` twice in a row, so that the first Lisp
-image can execute deployments in parallel while the second forks into the
-chroot (typically by having a ``DEPLOYS`` property with connection type
-``:SBCL`` as one of the properties applied by a deployment whose connection
-chain itself ends with ``:SBCL``).
diff --git a/doc/ideas.rst b/doc/ideas.rst
index e93e42d..11f8c12 100644
--- a/doc/ideas.rst
+++ b/doc/ideas.rst
@@ -61,10 +61,11 @@ Core
 - A CONCURRENTLY combinator for property application specifications, which
   means to apply each of the enclosed properties in parallel.  Particularly
   useful surrounding a set of DEPLOYS applications, to concurrently deploy a
-  number of hosts.  We use ``WITH-CURRENT-DIRECTORY`` in various places, so we
-  may not be able to do this using threads.  But if we want to do it with lots
-  of forking, then practically speaking usage of this combinator will be
-  restricted to connection chains which start up remote Lisp images.
+  number of hosts.  Now that we don't call fork(2) while executing
+  deployments, we ought to be able to do this using threads, and so it can
+  work in the root Lisp too.  However, we still use ``WITH-CURRENT-DIRECTORY``
+  in various places.  Perhaps that macro could be changed to only affect RUN,
+  MRUN etc. for the sake of enabling multithreading.
 
 - It might be useful to have a restart for the case where an attempt is made
   to apply a list of properties containing some ``:LISP`` properties with a