tclsh does not run the Tcl event loop unless, the script blocks. In that case it's not possible to continue processing commands from stdin until the event loop exits. This is not always a desireable situation in the NSCLDAQ. Sometimes we'd like to have events (like timers e.g.) in the background, or socket servers running while being live to events.
The CTCLLiveEventLoop is a class that can support this operation. It is a singleton class, since A Tcl application can only have a single event loop, however since a Tcl application may have more than one interpreter it is necessary to start the event loop on a specific interpreter. That interpreter is the one that will receive interactive commands. If the interpreter is not passed in when the event loop is started, the interpreter associated with the application is used (gpApplication).
Differnences from tclsh's input loop: prompt1 is: "% " while prompt2 is "-- " if there are no tcl_prompt1/tcl_prompt2 procs defined. If defined, those are honored.
NOTE: This class is unix specific. It uses file events which are not implemented on Windows. It ought to work just fine on Macs but has not been tested there.
void CTCLLiveEventLoop::stop |
( |
| ) |
|
This stops the event loop. The event loop waits for events up to some time out specified by setStopLatency. Between events and after waits timeout, the software will check to see if m_isRunning is still true. If not the event loop function returns.
Thus there can be a latency between stopping the event loop and it actually stopping.
Since serveral mutually unaware actors could be attempting to stop the event loop, it is not an error to stop an already stopped event loop.