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: weird behaviour of SNL test program running on Soft IOC on LINUX |
From: | "Oleg Makarov" <[email protected]> |
To: | "J. Lewis Muir" <[email protected]>, "Mark Rivers" <[email protected]> |
Cc: | [email protected], "Stepanov, Sergey" <[email protected]>, EPICS tech-talk <[email protected]> |
Date: | Mon, 16 Mar 2009 16:43:26 -0500 |
Hi Lewis,yes, you are right, adding a pvFlush() function call after each pvPut/pvGet call solves the problem: test program being run on LINUX Soft IOC behaves as expected.
It is strange though that it does not work without explicit pvFlush() calls. If "+a" option is not set for snc compiler, one would expect synchronous IO to be performed.
Oleg----- Original Message ----- From: "J. Lewis Muir" <[email protected]>
To: "Oleg Makarov" <[email protected]>Cc: "Mark Rivers" <[email protected]>; "EPICS tech-talk" <[email protected]>; <[email protected]>; "Stepanov, Sergey" <[email protected]>
Sent: Monday, March 16, 2009 3:34 PMSubject: Re: weird behaviour of SNL test program running on Soft IOC on LINUX
On 3/16/09 4:08 PM, Oleg Makarov wrote:Hi Mark, I tried the test with this fix. The problem is not resolved by epicsThreadSleep code change in the osdThread.c. CA requests are not being send out as they arise, some buffering of the requests occurs to make network communication more efficient. If you look at the camonitor output, it shows a 3-second period, exactly as expected. Are there way to force CA requests to go out as they arise, with no buffering?Hi, Oleg. pvFlush() will flush the SEQ PV layer, but maybe that's not what you're asking about. You can also do a synchronous put: pvPut(str_cmd, SYNC); But still, I don't understand why str_rsp would ever contain one of the commands from str_cmd (e.g. "I522") like your output shows, unless something is messed up with what's happening in and beyond "{dev}StrCmd" and "{dev}StrRsp". Lewis