Apple Darwin User Manual download pdf (Page 42)

Because the scope of the supported API is limited, it is much more practical for you to support them through

function-call marshaling, because you can hand-code routines for each function or class that you intend to

call across an address-space boundary instead of relying on programmatically generated functions and classes.

As with programmatic function-call marshaling, you must be particularly careful when working with pointers.

If pointer arguments are of a known type and size, it is relatively easy to work with them. However, you may

encounter problems if you do not know the size of the referenced object and if you need to byte swap or

otherwise manipulate the pointer contents during the boundary crossing.

C++ and Objective-C classes are a bit harder. You can’t simply pass pointers to classes, because they won’t be

valid on the other side of the communications channel. However, if the number of classes is limited, you can

emulate class pointers by using stub classes in the helper host that contain an extra member variable that

stores the address of the real class instance on the host side.

Similarly, you must emulate any callback pointers passed as arguments, because the callback pointer is

meaningless in the context of the main host application. You can emulate these pointers either through

message passing in the reverse direction or through RPC from the primary host into the helper host.

When you use limited function-call marshaling, your helper host can be very compact and completely

transparent. However, your stub libraries must contain every function that you intend to override. For large

plug-in APIs, this approach can be daunting, particularly if you are not in control of the API itself.

Remote Hosting

Remote hosting is strongly recommended for most helper host implementations because it is relatively easy

to implement reliably. With remote hosting, instead of relying on knowledge of the plug-in architecture, you

rely on your knowledge of the plug-in host itself. Because you are in control of the code in question, you will

be aware of any changes to the API. Also, because the interface between a host and its built-in engine rarely

involves callback pointers, you can use a simpler communication mechanism.

With remote hosting, you create a stripped-down version of your application that displays no user interface

itself (except possibly a mirror of the menu bars with appropriate message passing to the main application).

This miniature application should include a full set of data processing functionality. In this model, the host

application passes a chunk of data to the helper host, then relies on the helper host to process the data just

as the host application’s built-in plug-in engine would.

You may choose to add a command-line flag (using argc and argv) to your application and, upon seeing that

flag, call a separate initialization routine in which only the back-end functionality is configured. If you do, your

helper host can simply be another running instance of your main application binary.

Cross-Architecture Plug-in Support

Choosing a Helper Host Architecture Model

1 2 ... 37 38 39 40 41 42 43 44 45 46 47 ... 67 68

No comments

Apple Darwin User Manual Page 42