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: Proglem doing CA calls after catching a signal |
From: | Till Straumann <[email protected]> |
To: | Eric Norum <[email protected]> |
Cc: | Robert Soliday <[email protected]>, tech-talk <[email protected]> |
Date: | Mon, 26 Jul 2004 11:11:41 -0700 |
Robert Soliday wrote:
After upgrading to Epics/Base 3.14.6 from 3.13.10 I am having difficulty handling signals. In one of our applications if the user does a control-C it is suppose to trap the signal and restore the PVs to their original values. Odds are the control-c will occur while in a ca_pend_event call. When I go to do a ca_pend_io in the interrupt handler I get the error:
pthread_mutex_unlock failed: error Not owner fatal error: epicsMutexOsdUnlock
I have included a simple program that displays the same problem. If anyone knows the proper way of doing CA calls after catching a signal please let me know.
I was wondering when we'd have to address the grotty details of POSIX thread/signal interaction. As a first pass, perhaps we should have epicsThreadCreate call sigprocmask to block signals in all but the main (startup) thread? (assuming, of course, that sigprocmask applies on a thread-by-thread basis?
Can you use something other than signals to do this? For example, could you move the work to another thread and have the interactive thread wait for a return to be typed and then use epicsEventSignal or something like that to communicate between the threads?
My guess is that trying to make EPICS robust in the face of signals is going to uncover lots of problems in the thread/signal support of the various platforms we're now supporting.
Good guess. I had a taste of this when making labCa (matlab/scilab - CA interface) calls Ctrl-C interruptible. Just dealing with three platforms (linux, solaris and win32) reveals that the details of all of those are very different and a pain to deal with.