Performing Streaming on a Separate Thread

The previous example is intended to demonstrate how data streaming would be performed on the same thread as the application. The main application code, HOOPS and the data reading/streaming process all happen sequentially and synchronously within the same thread, and control does not return to the main application loop until reading is complete. However, it may be desirable to have the data read from the file asynchronously, independent of application processing. This would allow the user to interact with the application in a normal fashion, while data is still being streamed from the file which may be local, or could be coming in via a slower network connection.

This can be supported by performing the reading on a thread which is separate from the application. After this thread reads in data of a user-specified size, it would post a message to the main application event loop indicating that it has a new chunk of data ready for processing. Then, the main application loop would pass that data to the ParseBuffer function for processing and insertion in the HOOPS database.

When using the 3dGS-specific classes and the default system options of HOOPS/3dGS, any calls to the ParseBuffer method must occur on the same thread that the main HOOPS/3dGS database is running on, which is typically the main application thread. ParseBuffer makes calls to HOOPS/3dGS which is not reentrant by default. That means it is not safe for two separate threads to modify the same HOOPS database. If you want to call ParseBuffer on a thread that is different from the HOOPS/3dGS thread (so that the work of decompressing/decoding the buffers is done asynchronously and potentially concurrently), then HOOPS/3dGS must be put into ‘reentrant’ mode. Refer to the multithreading section of the HOOPS/3dGS Programming Guide for information on HOOPS/3dGS multi-threading support.

Creation of a separate thread and posting a message to the main application loop involves platform-specific logic.