Using co-processing utilities

Co-processing allows an external process to communicate with the user via a menu, form, or text frame. A co-process does not have direct access to the terminal's screen. It communicates with the FMLI application, which can then post the messages in the frame that contains the co-processing descriptors or take other appropriate actions.

The co-processing feature in FMLI consists of five built-in utilities: cocreate, cosend, cocheck, coreceive, and codestroy, which support interprocess communication.

The cocreate utility is responsible for initializing the co-process and setting up pipes between it and FMLI. The codestroy utility is responsible for cleaning up when the communication has been completed. The utility cosend is used to send information to the co-process via the pipe and block (wait) for some response by the co-process. The -n option to cosend performs a ``no wait'' write. This means that cosend will send information to the co-process but will not block for a response. The cocheck utility checks the incoming pipe for information. The coreceive utility performs a ``no-wait'' read on the pipe. The purpose of these built-in utilities is to provide a flexible means of interaction between FMLI and a co-process; to be responsive to asynchronous activity.

It is important to note that information passed to FMLI from a co-process is treated as text only. FMLI commands (for example, open, close, update) will not be recognized by FMLI unless they become the value of a descriptor of type command.

To illustrate the use of co-processing, consider a UNIX system program that wishes to ``talk'' to the user as it executes (an interactive program). The following sample menu displays the item talk. When talk is selected, the backquoted expression creates the co-process and then opens an ``interactive'' form, Form.talk.

   menu="My Menu"
   name="talk"
   action=`cocreate -i MYPROC talk` open Form.talk

Menu.talk: an example of co-processing

In the form frame definition file Form.talk, shown in ``Form.talk: an example of co-processing'', the following occurs:

• The close descriptor is responsible for destroying the communication.

• The reread descriptor checks the pipe and rereads the frame definition file if there is information pending.

• Field 1 is an inactive field, used simply to display text received from the co-process.

• Field 2 is an active field which will get information from the user and send it to the co-process (cosend). This is done via the valid descriptor which is evaluated when a field value changes.

• A SLK, <F8>, is defined to abort the co-process at any time. This is done by forcing a close operation (as usual, the descriptor close is evaluated when a frame is closed).

   form="Talking ..."
   close=`codestroy MYPROC`
   reread=`cocheck MYPROC`
   

   name=""
   fcol=0
   rows=5
   columns=20
   inactive
   value="`coreceive MYPROC`"
   

   name=""
   fcol=0
   columns=20
   valid=`cosend -n MYPROC "$F2"`TRUE
   

   name=abort
   button=8
   action=`message "Communication stopped ..."`close

Form.talk: an example of co-processing

The following code segment illustrates how an interactive co-process (in this case talk) may be structured:

   response="nothing"
   while :
   do
   echo "I received $response."
      vsig
      read response
      if [ "$response" = "goodbye" ]
      then
         break
      fi
   done
   echo "goodbye"
   vsig

talk: an example of a co-process

The executable vsig(1fmli) is used to send a signal telling the interpreter that information is pending. This interrupt causes reread to be evaluated. For more information about co-processing, see the coproc(1fmli) manual page.