 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
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.