Understanding the Synergy I/O Hooks API
The Synergy I/O hooks API class objects are called automatically when needed to perform pre- and post-I/O operations—you don’t call them yourself. You can pass a constructor to the I/O handler that tells it to come and use a virtual hook method when certain operations happen to a file.
The I/O hooks API consists of the following:
-
The IOHooks class makes it possible to perform custom I/O without changing any code in your existing I/O routines.
-
The IOEventMask enumeration sets the bit masks for the I/O operation hook qualifiers.
-
The IOFlags enumerator indicates an I/O statement qualifier.
The IOHooks object class provides 4 constructors and 17 pre- and post-operation virtual hook methods that you create using the specified names and method signatures to do whatever you want them to do. If implemented, these methods are then called automatically in conjunction with other operations (for example, a FIND, a READ, a WRITE, etc.). (See Pre-operation hook methods and Post-operation hook methods for specific details.) Your implementation of these methods must exactly match the method signature you’re overriding; otherwise, you’ll get a “No suitable Method found to override” error (NOOVR) when compiling. You can extend these methods to implement dynamic operation logging, perform pre- or post-I/O processing in your application, or whatever else you need them to do.
The class that you create by extending the IOHooks base class must implement at least one constructor and override at least one hook method, depending on which I/O operations you need. In your application itself, you’ll create an instance of your class and register it as a file I/O event handler for a channel or Select statement.
For example, if you want to perform some processing before and after a READS operation, you’ll override the READS pre- and post-operation hook methods. Your custom pre-operation method will then be executed before any READS occurs. The READS itself is issued as soon as your method exits, followed immediately by your post-operation hook method. Upon exit of the post-operation hook method, your application resumes.
You should avoid performing network operations with I/O hook routines.
You can use I/O hooks globally when you create a SYN_GLOBALHOOKS_OPEN routine. With regular (non-global) I/O hooks, you add an IOHooks constructor somewhere in your code, and then when that code is executed, your I/O hooks become active. For global I/O hooks, you instead add the IOHooks constructor to your SYN_GLOBALHOOKS_OPEN() implementation, and then after each OPEN, your routine can activate I/O hooks on chosen files and/or open modes.
To use global I/O hooks on OpenVMS, your I/O hooks routine must be built into your mainline .exe file. To use global I/O hooks with Synergy .NET, your I/O hooks module must be included in your compile. |
Using global I/O hooks instead of non-global I/O hooks offers one big advantage. With standard I/O hooks, you need to link in a source module that contains your IOHooks logic and explicitly call a routine or execute some code that references that logic. With global hooks, you can activate the hooks simply by linking in the source module containing your IOHooks logic. Your application can be running without hooks, and then when you link in the module with IOHooks (and your SYN_GLOBALHOOKS_OPEN() implementation), your hooks become fully active, without modifying the rest of your application. In other words, you don’t need to conditionalize your application to instantiate the hooks object; all you need to do is link it in.
Global I/O hooks cannot be used with xfServerPlus.