EPICS RE: cygwin and DOS caget, caput running slow at end due to ca_context

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 2025	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 2025
<== Date ==>		<== Thread ==>

Jay,

I am on windows 7, but have used EPICS also on vista and 2000 w/o seeing such delays, but I use only

win32-x86 and win32-x86-mingw.

This might be an issue with cygwin-x86 (POSIX emulation on windows) versus win32-x86 or win32-x86-mingw (both native ports). If we are certain that it is waiting around in epicsThreadPrivateGet, which is typically expected to be a very fast and efficient call, then perhaps that is further evidence of something fishy in cygwin.

However, sometimes the debuggers are confused about where a blocking thread is actually parked. Another likely place is lingering in the socket close function. In my experience, the MS debugger can be habitually confused about where a thread is when it is parked in the winsock dll.

Jeff

______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is

not necessarily a good idea. It is hard to be sure where they

are going to land, and it could be dangerous sitting under them

as they fly overhead. -- RFC 1925

From: [email protected] [mailto:[email protected]] On Behalf Of Jay Steele
Sent: Wednesday, February 16, 2011 4:07 PM
To: [email protected]
Subject: RE: cygwin and DOS caget, caput running slow at end due to ca_context_destroy(), option to speed up execution?

Hi Mark and Jeff

Are you guys running Windows XP? My results on my Windows XP computer are different than yours for some reason. I measure about 5 seconds to run caget and caput. Here’s more information.

1. No significant delay using MEDM GUI CA client on the same Windows XP computer to get or modify PV values on VxWorks IOC.

2. For caget and caput, 5 second delay occurs inside function epicsThreadPrivateGet called from ca_context_destroy to access PV records on VxWorks IOC.

I could speculate that there is something wrong with my EPICS makefiles and I’m not using the correct option somewhere for the cygwin build, but I get the similar results (delay ~5 seconds) with the pre-compiled Win32 Extension caget function. Could there be some Windows XP environmental variable or setting for handling threads that I need to set?

When I add some print statements to track where the cygwin caget code is stalling, the code stalls for the 5 seconds at the last pthread_getspecific call inside epicsThreadPrivateGet. For some reason, the initial call to pthread_getspecific within epicsThreadPrivateGet function launches a succession of calls to epicsThreadPrivateGet. I cannot find where this recursive logic is. Here’s the output. I get the same output when I run caget to access a PV record field from the softIOC running on the same Windows computer, but without the ~5 second delay.

Epics/base/src/ca/access.cpp - ca_context_destroy(), calling epicsThreadPrivateGet with id = 5382720

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5382720, calling assert