Getting Started Documentation Glish Learn More Programming Contact Us
Version 1.9 Build 1556
News FAQ
Search Home


next up previous contents index
Next: Suppressing Stand-Alone Client Behavior Up: Internals Previous: Creating and Controlling Remote Clients

Transmitting Events

Glish uses three different forms of interprocess communication (IPC) for transmitting events. When the Glish interpreter creates a client it passes it special arguments telling it how to make its connection with the interpreter.

The most general form of IPC used by Glish is a socket connection. In this case, the client's arguments tell it to which host and port number to connect16.1. The client then opens a socket to that host and port, sends a message identifying itself, and uses the socket for its subsequence communication with the interpreter. This same mechanism is used when glishd must be started by the interpreter.

As an optimization, however, if a client is running on the same host as the interpreter then the interpreter will use pipes to communicate with the client instead. Experience has shown that using pipes locally can result in a substantial improvement in performance (a factor of 2 on SunOS). In this case, prior to creating the client the interpreter creates two pipes which the client inherits when the interpreter exec()'s it.

The link statement requires the creation of a separate connection between two clients. The interpreter sends the sending end of the link a special *link-sink* event. The Client Library of the sender intercepts this event, creates either a UNIX- or Internet-domain socket endpoint (the former if the sender and receiving reside on the same host), creates a *rendezvous* event describing how to connect to endpoint (i.e., which host and port), and returns that event to the interpreter. When the interpreter receives a *rendezvous* event it sends a corresponding *rendezvous-resp* event to the link receiver, and reflects back a *rendezvous-orig* event to the sender (this second event isn't strictly necessary, but used to be necessary to avoid deadlock). The sender and receiver then rendezvous using the given socket, establishing the separate connection between them.

The unlink statement suspends the separate connection between two Glish clients. It is implemented by sending a *unlink-sink* event to the sender-side of the link. The sender then marks the link as inactive; it does not destroy the link, however, since it might later be resurrected via another link statement.

With shared clients, glishd must be started by root. This is because glishd maintains a lot of information about the client that is shared by all Glish users. If glishd were not running as root, it could not control the ownership of processes it creates on behalf of many users. A shared client starts up like any normal client, but as part of its initialization process it connects to the published glishd port and registers itself as shared. Before any client is started, the Glish interpreter first attempts to check with glishd to see if the client is already running. glishd uses the information it collects as clients register themselves as shared to answer these requests. If the client is already running, the interpreter sends a "client" event to glishd which then forwards the event the preexisting client.


next up previous contents index
Next: Suppressing Stand-Alone Client Behavior Up: Internals Previous: Creating and Controlling Remote Clients   Contents   Index
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc., Washington, D.C.

Return to AIPS++ Home Page
2006-10-15