-/* On receipt of a signal that a child status has changed,
- loop asking about children with changed statuses until
- the system says there are no more.
- All we do is change the status;
- we do not run sentinels or print notifications.
- That is saved for the next time keyboard input is done,
- in order to avoid timing errors. */
-
-/** WARNING: this can be called during garbage collection.
- Therefore, it must not be fooled by the presence of mark bits in
- Lisp objects. */
-
-/** USG WARNING: Although it is not obvious from the documentation
- in signal(2), on a USG system the SIGCLD handler MUST NOT call
- signal() before executing at least one wait(), otherwise the handler
- will be called again, resulting in an infinite loop. The relevant
- portion of the documentation reads "SIGCLD signals will be queued
- and the signal-catching function will be continually reentered until
- the queue is empty". Invoking signal() causes the kernel to reexamine
- the SIGCLD queue. Fred Fish, UniSoft Systems Inc. */
+/* On receipt of a signal that a child status has changed, loop asking
+ about children with changed statuses until the system says there
+ are no more.
+
+ All we do is change the status; we do not run sentinels or print
+ notifications. That is saved for the next time keyboard input is
+ done, in order to avoid timing errors.
+
+ ** WARNING: this can be called during garbage collection.
+ Therefore, it must not be fooled by the presence of mark bits in
+ Lisp objects.
+
+ ** USG WARNING: Although it is not obvious from the documentation
+ in signal(2), on a USG system the SIGCLD handler MUST NOT call
+ signal() before executing at least one wait(), otherwise the
+ handler will be called again, resulting in an infinite loop. The
+ relevant portion of the documentation reads "SIGCLD signals will be
+ queued and the signal-catching function will be continually
+ reentered until the queue is empty". Invoking signal() causes the
+ kernel to reexamine the SIGCLD queue. Fred Fish, UniSoft Systems
+ Inc. */