On May 31, 2006, at 7:43 AM, Dirk Zimoch wrote:
Eric Norum wrote:
This sounds like a task starvation issue. It appears that the read task is looping at a higher priority than the event timer callback task and so is preventing the callback from running. My suspicion is that it's the vxWorks version of select() which is not rounding the timeout up to at least one tick. If so, the problem will still be present in the latest version of ASYN.
I called spy and found that the asyn port thread is indeed using up all CPU time at higher priority than e.g. CA or the timerQueues.
Good. The problem has been identified.
The latest version of ASYN will not have this "read forever" problem on vxWorks. It will still have "issues", though.
Consider the following situation:
1) vxWorks with a 100 Hz system clock.
2) An ASYN TCP/IP or UDP/IP read request with a timeout of 4 msec.
The read request will return any characters already present. If no characters are present the request will *not* wait for up to 4 msec, but will return immediately. This could cause the thread performing the read to loop and prevent lower-priority threads from getting any CPU time. (I could argue that issuing such short-timeout calls in a loop is a sign of a bad application, but it would be best if ASYN helped protect programmers from themselves)
As a suggestion, how about we modify the ASYN IP port driver so that on vxWorks the local poll() routine rounds up non-zero timeouts to a miniumum of 1/epicsThreadSleepQuantum()?
Advanced Photon Source
Argonne National Laboratory