[launchd-changes] [23899] trunk/launchd/src/launchd_core_logic.c

[source_changes at macosforge.org]

Revision: 23899
          http://trac.macosforge.org/projects/launchd/changeset/23899
Author:   dsorresso at apple.com
Date:     2009-04-17 14:37:51 -0700 (Fri, 17 Apr 2009)
Log Message:
-----------
<rdar://problem/6787083> Finder refuses to launch after Force Quit (error -10810)

Modified Paths:
--------------
    trunk/launchd/src/launchd_core_logic.c

Modified: trunk/launchd/src/launchd_core_logic.c
===================================================================
--- trunk/launchd/src/launchd_core_logic.c	2009-04-16 22:18:10 UTC (rev 23898)
+++ trunk/launchd/src/launchd_core_logic.c	2009-04-17 21:37:51 UTC (rev 23899)
@@ -8532,9 +8532,24 @@
 	otherj = job_dispatch(otherj, true);
 
 	if (!job_assumes(j, otherj && otherj->p)) {
+		/* <rdar://problem/6787083> Clear this flag if we failed to start the job. */
+		otherj->stall_before_exec = false;
 		return BOOTSTRAP_NO_MEMORY;
 	}
 
+	/* If any of these proceeding steps fail, we return an error to the client.
+	 * the problem is that, if the client has requested the job be stalled before
+	 * exec(2), the client won't be able to uncork the fork(2), leaving the job
+	 * forever stalled until the client tries again and we successfully start
+	 * the job.
+	 *
+	 * See <rdar://problem/6787083> for more about the implications.
+	 *
+	 * Fortunately, these next actions should pretty much never fail. In the
+	 * future, we should look at cleaning up after these failures if the job
+	 * was started in a stalled state.
+	 */
+
 	kern_return_t kr = task_name_for_pid(mach_task_self(), otherj->p, out_name_port);
 	if (!job_assumes(j, kr == 0)) {
 		return kr;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/launchd-changes/attachments/20090417/e09867b4/attachment.html>