Use of ProcessSystemEvents() in a Dedicated Data Logging Thread

[MadHacker]

In my application, I have moved data logging (writing text data to hard disk) into its own thread.  Things are working fine, but I wanted to ask about using ProcessSystemEvents() and Delay().

Below is my code.  I hope my bracket style doesn't confuse anyone.  I've omitted error handling for the sake of readability in this example. 

The thread runs and receives data asynchronously, and writes the data to disk.  It does no GUI updates, but I may later add an a panel with text box for displaying logged data in real time.  But at the present, there are no GUI updates.

Notice how I've used Delay().  Is this necessary?  If so, is my usage sufficient?

And what about ProcessSystemEvents()?  Should my code call it? 

And I assume that if I add a GUI to the thread, I must call ProcessSystemEvents() periodically?  Yes?

Thanks in advance.

int CVICALLBACK thread_fcn(void* init_data) {
   char         log_file_path_and_name[MAX_PATHNAME_LEN+1];
   Cmd          cmd;
   CmtTSQHandle tsq_handle;
   FILE*        fp;
   tsq_handle = *(CmtTSQHandle*) init_data;   
   while (1) {
      if (CmtReadTSQData(tsq_handle, &cmd, 1, TSQ_INFINITE_TIMEOUT, 0) == 1) {
         switch (cmd.id) {
            case BEGIN_TEST:
               strcpy(log_file_path_and_name, cmd.data.log_file_path_and_name);
               fp = fopen(log_file_path_and_name, "w");
               break;
            case LOG_TEXT:
               fprintf(fp, cmd.data.text);
               break;
            case END_TEST:
               fclose(fp);
               break;
            case TERMINATE:
               return 0;
            }
         }
      Delay(0.01);
      }
   return 0;
   }

[NickelsAndDimes]

Hi MadHacker,

That delay() will slow down the rate that your program processes commands, which in turn lowers the CPU usage of your program. Unless you're intending for your program to process commands extremely rapidly, it's probably a good idea (you may even consider increasing it to 0.1 instead of 0.01).

As for ProcessSystemEvents(), does this thread have any sort of user interaction (like the user clicking a button on the front panel)? If so, then you'll want it somewhere in the code. If that's going to be handled by a different thread, you should be able to get away with it. I've linked documentation for this function below.

ProcessSystemEvents
http://zone.ni.com/reference/en-XX/help/370051T-01/cvi/uiref/cviprocesssystemevents/

[RobertoBozzolo]

I would try another approach by installing a callback on the thread-safe queue with CmtInstallTSQCallback () function: since you can pass the ID of the thread that is in charge of processing queue events you can maintain your basic structure while simplifying the thread structure (the loop should do absolutely nothing but processing events).

Furthermore, since your thread is intended to simply log data to a file, you could customize the queue callback to fire only on a certain amount or records received, in order to reduce disk I/O access which notoriously is a bottleneck: saving records one-by-one is usually a bad strategy..