4. A pseudo 'non-blocking' Cascade Connect data transmission
A simple method for protecting critical tasks in QNX so that they are non-blocking on the transmission of data to Cascade Connect is shown below.
The developer can prevent task 1 from blocking on the Cascade Connect program by placing a fetch program between the two. This fetch program polls for specific points from task 1 on a regular basis, which depends on how fast the MS-Windows computer can remove data from the TCP/IP socket buffer. If for some reason, the MS-Windows computer slows down and causes messages to back up in the TCP/IP buffer the effect will be to cause the fetch program to block on Cascade Connect and not the critical task 1. Because the fetch program only ever polls the critical task for information, task 1 is never send blocked to the fetch program. Data transmission from task 1 is always in the non-blocking reply part of the message transaction.