objective c - Drawbacks of building a background-only COCOA app as a launch daemon? -


are there drawbacks of building background-only cocoa app without gui , run launch daemon. use:

import <foundation/foundation.h> import <appkit/appkit.h> import <coredata/coredata.h> 

the primary advantage of using , not building objective-c command line tool offers implicit run-loop benefits including defined callbacks when application finishes launch or during termination. need explicitly implemented in command line app.

are there disadvantages such functionality break? launch of daemon deferred?

for daemon, there serious drawbacks using non-daemon-safe framework. technical note tn2083: daemons , agents – layered frameworks:

layered frameworks

most mac os x functionality implemented large system frameworks. many of these frameworks use mach-based services using bootstrap service. can cause sorts of problems if call them program references wrong bootstrap namespace.

apple's solution problem layering: divide our frameworks layers, , decide, each layer, whether layer supports operations in global bootstrap namespace. basic rule in coreservices , below (including system, iokit, system configuration, foundation) should work in bootstrap namespace (these daemon-safe frameworks), whereas above coreservices (including applicationservices, carbon, , appkit) requires gui per-session bootstrap namespace. …

in summary, concrete recommendations are:

  • when writing daemon, link daemon-safe frameworks (see framework cross reference).

  • when writing gui agent, can link framework.

  • if you're writing daemon , must link framework that's not daemon-safe, consider splitting code daemon component , agent component. if that's not possible, aware of potential issues associated linking daemon unsafe frameworks (as described in next section).

living dangerously

if daemon uses frameworks aren't daemon-safe, can run variety of problems.

  • some frameworks fail @ load time. is, framework has initialization routine assumes it's running in per-session context , fails if it's not.

    this problem rare on current systems because frameworks initialized lazily.

  • if framework doesn't fail @ load time, may still encounter problems call various routines framework.

    • a routine might fail benignly. example, routine might fail silently, or print message stderr, or perhaps return meaningful error code.

    • a routine might fail hostilely. example, it's quite common gui frameworks call abort if they're run daemon!

    • a routine might work though framework not officially daemon-safe.

    • a routine might behave differently depending on input parameters. example, image decompression routine might work types of images , fail others.

  • the behavior of given framework, , routines within framework, can change release-to-release.

the upshot of that, if daemon links framework that's not daemon-safe, can't predict how behave in general. might work on machine, fail on other user's machine, or fail on future system release, or fail different input data. living dangerously!

read whole technote full details.


Comments

Popular posts from this blog

php - failed to open stream: HTTP request failed! HTTP/1.0 400 Bad Request -

java - How to filter a backspace keyboard input -

java - Show Soft Keyboard when EditText Appears -