Re: IOC Threads blocking all signals

["Johnson, Andrew N. via Core-talk" <core-talk@aps.anl.gov>]

On 6/19/19 10:29 AM, Ralph Lange via Core-talk wrote:

Question:

It seems (looking at start_routine() in libCom/osi/osd/posix/osdThread.c) that all threads that the IOC starts are blocking all signals.

Is that correct, or am I missing something?

If that's correct, why is it done?

I concur with Eric's memory. I believe that before we did that a signal to the IOC process could get picked up by *any* thread, many of which were unprepared for the possibility. When a specific thread wants to respond to a signal it should be explicitly enabling it anyway.

We have a case where a separate process started from an EPICS IOC subordinate (driver) thread - via fork() and execv() calls - seems to be "immune" against all attempts to kill it

The child side of the fork() call needs to re-enable the default signal handling before it calls exec(), I think Eric suggested that too.

There are of course horror stories about mixing threads and fork():
  https://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

Any sockets opened using the epicsSocketCreate() or epicsSocketAccept() routines do have the FD_CLOEXEC flag set so they are protected, which should cover most network FDs (IOC, Asyn etc.).

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.