Re: screen update

>From: ridder@informatik.uni-koblenz.de (Hanno Ridder) >Subject: screen update >Date: 11 Jan 1995 12:21:33 GMT >X-Informix-List-Id: <news.10717> >An application displays information about the contents of a table on the >screen. How can the application get the information when the table is >updated by another application? This is necessary to update the screen. >Is it possible to avoid polling? There is no simple way to avoid polling. The complex mechanisms for avoiding polling require, at a minimum, modifications to the applications which are interested in being notified when some table changes (AppTypeA), and either modifications to the applications which update the tables which AppTypeA programs want to know about (AppTypeB) or specialized triggers on the tables which notify the AppTypeA programs when some interesting table is changed. For example, you could arrange that AppTypeA programs record that they are running in some table -- you'd store the process ID -- and these programs remove this record when they terminate. They also set up a signal handler to handle some not-otherwise-used signal (eg SIGUSR1). On receipt of that signal, the programs arrange to note that the data has changed and then undertake to update the screen as appropriate. This can be very tricky in its own right, especially when you remember that the signal handler may be called during an input operation. The AppTypeB programs have to arrange to send the appropriate signals to the AppTypeA programs when the critical tables are changed. Any omission causes events to occur and not be notified. Alternatively, you could consider using a stored procdure which is triggered on changes to the relevant tables which notifies the AppTypeA programs when an update (or insert or delete) occurs. None of this is remotely simple, but I have seen it done for critical tables in an application which was monitoring the state of a production line and needed to notify the operators when certain types of fault were detected. Before trying this, you need to be utterly confident in your ability to handle Unix signals correctly. You also have to ensure that you don't try to do any SQL operations in the signal handler if there is already an operation in progress -- it won't work. All in all, this is not recommended. If you try it, on your own head be it. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>