site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Sorry, davez On Sep 30, 2005, at 8:49 AM, Graham J Lee wrote: Cheers, _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Today, launchd's operating goal is to find *any* reason to run a job and run it. launchd tries hard to stay out of the business of providing policy mechanisms like this for multiple reasons: 1) If it isn't OK to run now, then when? Should it just be skipped, or delayed? 2) Pathological cases. What if the laptop is always on battery when awake and asleep when charging the battery? 3) A slippery slope. This change adds two new libraries to launchd's link line. I've seen other requests to monitor other frameworks to provide limits like this (the SystemConfiguration framework for example). We could easily end up with launchd linked against dozens of frameworks on the system. launchd is too fundamental to the system to be risking linking against so many libraries. 4) Given the above problems, and the fact that people eventually want other limits, we're faced with the inevitable desire to have some language to express the limits. Linking against an interpreter is arguably a layering violation for something as fundamental to the system as launchd. It certainly provides for an explosion of complexity and therefore risk for launchd. Why? launchd is a single- threaded state engine, therefore any misbehaving script would hang launchd. Sure the scripts could be put on their own threads, but at that point, why not have a full blown process managed by launchd? For all of these reasons, I don't see limits like this being added to launchd any time soon. Dave Zarzycki wrote: On Sep 29, 2005, at 3:57 PM, Graham J Lee wrote: OK, well if it *will* work then I'll get on to testing. I suppose I was unjustly worried - even if WindowServer doesn't come up properly then at least getty ought to.... Just remember, Command-S will boot you up into single user mode, where you should be able to fix most mistakes. Failing that, you'll need a second partition or disk to boot from to undo mistakes. Thanks. As it turned out I didn't need to be so paranoid - it worked well. This iBook is now running a variety of launchd which will not run a job if NotOnBattery is true and the system is found to be powered from the battery. There's a patch at Radar# 4281025 and at http://bugzilla.opendarwin.org/show_bug.cgi?id=5200 (which I've assigned to myself - I don't know whether that's what I was supposed to do but as I'd fixed the bug I guessed it was ;-). Graham. This email sent to site_archiver@lists.apple.com