Although Callable IDL is very powerful and convenient, it is not always the best method of communication between with other programs. There may be easier approaches that will solve a given problem. See Supported Inter-Language Communication Techniques in IDL for alternatives.
Note: IDL will not integrate with all programs. This topic will help you decide when Callable IDL is and is not appropriate.
Technical Issues Relating to Callable IDL
IDL makes computing easier by raising the level at which users interface with the computer. It is natural to think that calling IDL from other programs will have the same effect, and under the correct circumstances this is true. However, using Callable IDL is not as easy as using IDL.
The same things that make IDL powerful at the user level can make it difficult to include in other programs. As an interactive, interpreted language, IDL is a decidedly non-trivial object to add to a process. Unlike a simple mathematical subroutine IDL includes a compiler, a language interpreter, and related code that the caller must work around. As an interactive program, IDL must control the process to a high degree which can conflict with the caller’s wishes.
The following list touches on a few issues that you may encounter.
UNIX IDL Signal API
IDL uses UNIX signals to manage many of its features, including exception handling, user interrupts, and child processes. The exact signals used and the manner in which they are used can change from one IDL release to another. Although the IDL signal API (described in IDL Internals: UNIX Signals) allows you to use signals in an IDL-compatible way, the resulting constraints may require changes to your code.
IDL Timer API
IDL’s use of the process timer requires you to use the IDL timer API instead of the standard system routines. This restriction may require changes to some programs. Under UNIX, the timer module can interrupt system calls. Timers are discussed in IDL Internals: Timers.
GUI Considerations
Most applications will call IDL and display IDL graphics in an IDL window. However, programmers may want to write applications in which they create the graphical user interface (GUI) and then have IDL draw graphics into windows that IDL did not create. It is not always possible for IDL to draw into windows that it did not create for the reasons described below:
X Windows
The IDL X Windows graphics driver can draw in windows it did not create as long as the window is compatible with the IDL display connection. However, the design of IDL’s X Windows driver requires that it open its own display connection and run its own event loop. If your program cannot support a separate display connection, or if dividing time between two event loops is not acceptable, consider the following options:
- Run IDL in a separate process and use interprocess communication (possibly Remote Procedure Calls), to control it.
- If you choose to use Callable IDL, use the IDL Widget stub interface described in Adding External Widgets to IDL, to obtain the IDL display connection, and create your GUI using that connection rather than creating your own. The IDL event loop will dispatch your events along with IDL’s, creating a well-integrated system.
Microsoft Windows
At this time, the IDL for Windows graphics driver does not have the ability to draw into windows that were not created by IDL.
Program Size Considerations
On systems that support preemptive multitasking, a single huge program is a poor use of system capabilities. Such programs inevitably end up implementing primitive task- scheduling mechanisms better left to the operating system.
Troubleshooting
Troubleshooting and debugging applications that call IDL can be very difficult. With standard IDL, malfunctions in the program are clearly the fault of NV5 Geospatial Solutions and given a reproducible bug report, we attempt to fix them promptly. A program that combines IDL with other code makes it difficult to determine where the problem lies. The level of support we can provide in such troubleshooting is minimal. The programmer is responsible for locating the source of the difficulty. If the problem is in IDL, a simple program demonstrating the problem must be provided before we can address the issue.
Threading
IDL uses threads to implement its thread pool functionality which is used to speed numerical computation on multi-CPU hardware. Despite this, it is essentially a single threaded program and is not designed to be called from different threads of a threaded application. Attempting to use IDL from any thread other than the main thread is unsupported, and may cause unpredictable results.
Inter-language Calling Conventions
IDL is written in standard ANSI C. Calling it from other languages is possible, but it is the programmer’s responsibility to understand the inter-language calling conventions of the target machine and compiler.
Appropriate Applications of Callable IDL
Callable IDL is most appropriate in the following situations:
- Callable IDL is clearly the correct choice when the resulting program is to be a front-end that creates a different interface for IDL. For example, you might wish to turn IDL into an RPC server that uses an RPC protocol not directly supported by IDL, or use IDL as a module in a distributed system.
- Callable IDL is appropriate if either the calling program or IDL handles all graphics, including the Graphical User Interface, without the involvement of the other. Intermediate situations are possible but more difficult. In particular, beware of attempts to have two event/message loops.
- Callable IDL is appropriate when the calling program makes little or no use of signals, timers, or exception handling, or is able to operate within the constraints imposed by IDL.