Disable System Events in Com Functions

[Jackson_Peacock]

While debugging a program of mine I discovered that system (gui) events are being processed inside of calls to the serial port library. I did not realize that this was the case, and am somewhat stumped as to how to proceed now. Here is my (simplified) main loop:

while (!done) {
    UpdateFromSerialPort (&someDataStructure);
    ProcessSystemEvents();
}

One of the menu items in my program is to load a new file. In doing so, it frees the existing data structures, and mallocs new ones to match the configuration. Sometimes when I click that menu item, it is processed not during the call to ProcessSystemEvents where I would expect, but in ComWrt within UpdateFromSerialPort (according to the callstack in the debugger). This causes the data structures to be reallocated and when ComWrt returns, UpdateFromSerialPort will attempt to access the old data structures that were passed to in, resulting in a memory access error. I have noticed this problem in calls to some other CVI functions as well.

I'm not sure how to deal with this. Normally for single threaded (callback-based) programs, you can just assume that each each callback is atomic (won't be interupted by other callbacks), and use that fact to protect access to shared data structures. However if a bunch of these CVI function calls are potential entry points for callbacks, that completely blows that strategy out of the water. For multithreaded programs, I would simply put a mutex around all the accesses to the data structure, but that also won't work in this case, as is would cause a deadlock in the the nested callbacks.

Is there a way to disable processing of system events within all CVI function calls other than ProcessSystemEvents? Is there a list of CVI library calls that allow processing of system events in them, so I can know to avoid them?

[RobertoBozzolo]

I am not aware of a call to ProcessSystemEvents or some equivalent function inside Com functions and I never observed a situation like your in my experience. As far as I know functions do are atomic unless you explicitly embed a call to ProcessSystemEvent; I seem to remember also that when a control callback finish executing it implictly fires such a call, but I'm not sure.

If you are sure that there is no hidden ProcessSystemEvent nested somewhere in your function(s), nor a callback that is firing based on other events (asyncronous timers and so on) that include such call, you could try using a global flag set at UpdateFromSerialPort beginning and reset at the end. This variable could be tested in every control callback so that if on it returns doing nothing and swallowing the event.

[Jackson_Peacock]

Hi,
That was my understanding as well and I had never seen such behavior until now. I am using a somewhat non-standard setup for this project - I am linking the CVI 5.5 libraries into Borland C++, as this project has grown beyond 20,000 lines of code, and we decided it would be easier to maintain using C++. The transition has been going fine until I stumbled upon this error.  I am certain that I am not calling ProcessSystemEvents anywhere other than the main event loop.  I have a breakpoint in the callback for the menu function, and when the code stops there, the callstack sometimes shows that the callback was called from the main event loop function (on the line the ProcessSystemEvents is called). However sometimes it shows being called from with in my serial port code.

Actually, looking at it closer, it doesn't always occur on the line with ComWrt, but rather on the line after CmtGetLock (I plan on adding a second serial port thread in the future, so I put this lock around all my high-level serial port code). Ah, sure enough, I passed OPT_TL_PROCESS_EVENTS_WHILE_WAITING into CmtNewLock. Doh.

Changing that fixes the problem. Thanks for the reply.

    jackson