Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Predefined Events

Glish predefines several events for every client to provide automatic access to the client's state:

established

is generated when a client first begins running. Return of the client call does not guarantee that the client is now running (especially if the async=T option has been used. (See § 7.8.1, page , above.) A client's established event is usually of interest only with asynchronous clients, since you can send events to a client and execute whenever statements referring to a client before the client has become established.

unrecognized

is generated when a client does not recognize an event sent to it. By convention, clients also generate error events when an event sent to them is erroneous in some way (for example, a mandatory field is missing from the event's value), but error events are not (yet) automatically generated.

done

is generated when the client finishes successfully. Contrast with:

fail

is generated on behalf of a client that terminates abnormally. For example, if a client faults due to a bus error and crashes, the Glish interpreter detects the client's failure and generates a fail event. If communication with a client is lost due to network problems, though, Glish may not detect the problem for a long time.

terminate

can be sent to any client to tell it to exit. All clients are sent implicit terminate events when a Glish program terminates due to an exit statement (See § 5.8, page ).

These events form the mechanism by which you can control clients and detect their errors. In general, if a client generates an event which has no corresponding whenever specifying what to do when that event occurs, then the Glish interpreter generates a warning message. This message is not generated, though, for unnoticed established and done events.

Ideally the above events should apply to all agents and not just clients. This means that subsequences (see the next section) would generate and respond to these events, too. Presently, however, these events only apply to clients (``clients" here includes asynchronous shell commands; see § 7.8.2, page ).