54 kB PostScript reprint
D. L. Terrett
Rutherford Appleton Laboratory, Chilton, Didcot, Oxon OX11 0QX, U.K.
The Starlink software environment (Adam) is used for telescope control (on the JCMT & UKIRT), instrument control and data acquisition (at the AAO, La Palma, UK Hawaii telescopes), and data reduction (throughout the Starlink network). In the real-time environment of telescope and instrument control, an Adam system consists of several independent tasks cooperating by exchanging messages using the Adam inter-task messaging systems. Usually, one or more of these tasks has the job of providing the user interface.
When used for data reduction, there are also several tasks in the system but usually only two---the user interface and one of the data processing tasks---are active at any one time. This is because, although the system allows several data processing tasks to run simultaneously, controlling such a system with a traditional command line interface is clumsy and confusing.
The Adam software environment was designed to support a variety of user interfaces; there are three currently in use:
A graphical user interface is widely seen as the best way of satisfying the demand that Adam systems should be easier to use, and Tcl and the Tk toolkit have been selected as the most promising tools for writing such an interface. Other approaches considered were:
Tcl and Tk (Ousterhout 1994) were selected because of the ease with which prototypes can be generated and the freedom this gives for exploring a wide range of interface styles in a reasonable time. Its status as freely available software, and its acceptance in a range of disciplines (including astronomy), are also attractive features. An Adam user interface has to communicate with Adam tasks. This means extending Tcl with commands for sending and receiving messages via the Adam inter-task messaging system.
A typical Adam system consists of a user interface process plus one or more Adam tasks (processes); each task supports one or more commands (up to several hundred in the case of some data reduction tasks). The tasks are independent, and can all be processing a command at the same time.
The user interface uses the message system to control the task. There are four types of message that can be sent:
SET, GET and CANCEL messages are acknowledged by the task with a single message; an OBEY can result in the exchange of many messages between the user interface and the task. These messages are used by the task to request new values for parameters and to display information to the user.
The following Tcl commands have been created to allow Tcl to control Adam tasks:
If there are no messages in the message system queue when adam_receive is called, it will block until a message arrives. In a Tk application this will cause the user interface to ``hang''. For a GUI that is tightly bound to a single application, this is acceptable (in fact, it feels quite natural---the interface freezes while the application is busy, just like a conventional GUI application with the interface and application in a single process). However, for a user interface that controls several tasks, it is unacceptable.
The solution adopted (pending possible modifications to the message system) is to use two processes: one running the user interface and not communicating directly with tasks, and another, called the relay process (also written in Tcl), that does. The user interface sends messages to the relay task using the Adam message system, which forwards them to the Adam tasks. Replies from the Adam tasks go to the relay task, which forwards them to the user interface via a pipe. The relay task can safely call adam_receive since it does not have to respond to X events and the user interface never has to call adam_receive since all incoming messages are delivered via a pipe. The I/O on the pipe can be integrated with the X event loop with Tcl_CreateFileHandler.
When a GUI is being added to an existing application, the GUI has to handle prompts and information messages from the application; the number of messages and the order in which they arrive is unpredictable (except for very simple applications). Information messages can be difficult to display appropriately; for example, they may contain instructions to the user that only make sense in the context of a command line interface. Interactive graphical applications will bypass the user interface when doing the interaction and this results in an inconsistent interface style. Consequently, existing application will usually need some modification before a satisfactory GUI can be constructed.
An Adam application can be written specifically to be run by a GUI by ensuring that it never requests parameter values from the user interface and by formatting messages to be interpreted by the GUI rather than the user.
54 kB PostScript reprint