EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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  <20042005  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: Chris Larrieu <[email protected]>
To: tech-talk <[email protected]>
Date: Mon, 26 Jul 2004 14:19:19 -0400
Isn't the crux of the problem that there's no way to specify/predict which thread should handle a signal?


Till Straumann wrote:


Eric Norum wrote:

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.

Till



Replies:
Re: Proglem doing CA calls after catching a signal Eric Norum
Re: Proglem doing CA calls after catching a signal Robert Soliday
References:
Proglem doing CA calls after catching a signal Robert Soliday
Re: Proglem doing CA calls after catching a signal Eric Norum
Re: Proglem doing CA calls after catching a signal Till Straumann

Navigate by Date:
Prev: Re: Proglem doing CA calls after catching a signal Till Straumann
Next: Re: Proglem doing CA calls after catching a signal Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Proglem doing CA calls after catching a signal Till Straumann
Next: Re: Proglem doing CA calls after catching a signal Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·