Shawn,
Thanks for the explanation - it was good to have my suspicions
confirmed. From my experience, it seems that servicing events from
multiple sources using some fairly complex code can be done with little
problem provided the event code does not use common User Functions (in
fact, it shouldn't use User Functions also found in the application's
non-event code.
Barrie
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Thanks for the explanation - it was good to have my suspicions
confirmed. From my experience, it seems that servicing events from
multiple sources using some fairly complex code can be done with little
problem provided the event code does not use common User Functions (in
fact, it shouldn't use User Functions also found in the application's
non-event code.
Barrie
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Those of you that have been reading the reflector messages for a lengthy
time may remember that I have had code "race" problems on a number of
occasions. The symptom has been major sections of my application simply
stopping without error notification and the cause has always been
related to the need for multiple I/O event service routines.
The accepted solution has been to revise my event code so that it does
the absolute minimum (store the incoming data, set a flag, and exit),
leaving the complicated work for a single thread that monitors the
various flags. Unfortunately, this has always been easier said than done
and recently I have run into a situation where speed issues made complex
event code the only solution. Interestingly enough, it hasn't turned out
to be a problem despite the fact that the application has been servicing
1 second events for well over a month.
This got me to thinking about why my new service code works and some of
my previous attempts didn't. One possibility I can think of is that code
race problems only occur if "user functions" are included in the event
service loops; built-in functions and all the normal Vee objects can be
used without difficulty. To the best of my knowledge, multiple use of
the same user function has always been involved in my previous problems.
In at least one instance, the solution was to replace the user function
with a copy of its code "in-line".
Does anyone know if there is something about calls to user functions
that would allow race problems when calls to built-in functions prevent
them?
Barrie
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".