Coaxlink Programmer's Guide Euresys::EGrabber
Interface module – I/O Toolbox category
Callback function Data type numid prefix
onIoToolboxEvent IoToolboxData EVENT_DATA_NUMID_IO_TOOLBOX_
Interface module – CXP Interface category
Callback function Data type numid prefix
onCxpInterfaceEvent CxpInterfaceData EVENT_DATA_NUMID_CXP_INTERFACE_
Examples
We'll soon show a few complete example programs illustrating events and callbacks, but there is one more thing we
need to explain before we can do that: the context in which callback functions are executed. This is the subject of the
next section.
EGrabber flavors
When should the callback functions be called? From which context (i.e., which thread)? Thinking about these questions
leads to the definition of several callback models:
• The application asks the grabber: "Do you have any buffer or event for me? If yes, execute my callback
function now." This is a polling, synchronous mode of operation, where callbacks are executed when the application
demands it, in the application thread.
We'll refer to this callback model as on demand.
• The application asks the grabber to create a single, dedicated thread, and to wait for events in this thread. When an
event occurs, the grabber executes the corresponding callback function, also in this single callback thread.
We'll refer to this callback model as single thread.
• The application asks the grabber to create a dedicated thread for each of its callback functions. In each of these
threads, the grabber waits for a particular category of events. When an event occurs, the corresponding callback
function is executed in that thread.
We'll refer to this callback model as multi thread.
These three callback models all make sense, and each one is best suited for some applications.
• The on demand model is the simplest. Although its implementation may use worker threads, from the point of view
of the user it doesn't add any thread. This means that the application doesn't need to worry about things such as
thread synchronization, mutexes, etc.
• If the user wants a dedicated callback thread, the single thread model creates it for him.
When we have only one thread, things are simple. In this model, the grabber is used in (at least) two threads, so we
need to start worrying about synchronization and shared data.
• In the multi thread model, each category of event gets its own thread. The benefit of this is that events of one
type (and the execution of their callback functions) don't delay notifications of events of other types. For example,
a thread doing heavy image processing in onNewBufferEvent will not delay the notification of CIC events by
onCicEvent (e.g., events indicating that the exposure is complete and that the object or camera can be moved).
In this model, the grabber is used in several thread, so the need for synchronization is present as it is in the single
thread model.
20
To Next Page
Loading...
