Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Tue, 20 Jul 2004 11:51:36 -0500

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.

--

Eric Norum [email protected]

Advanced Photon Source Phone: (630) 252-4793

Argonne National Laboratory

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System