1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: asynDriver / epicsTimer bug |
From: | Eric Norum <[email protected]> |
To: | Dirk Zimoch <[email protected]> |
Cc: | TECHTALK Tech-Talk <[email protected]>, Mark Rivers <[email protected]> |
Date: | Wed, 31 May 2006 08:54:40 -0500 |
On May 31, 2006, at 7:43 AM, Dirk Zimoch wrote:
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()? -- Eric Norum <[email protected]> Advanced Photon Source Argonne National Laboratory (630) 252-4793 |