Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 26 Sep 2008 17:17:44 -0500

Hi David,

On Thursday 25 September 2008 14:06:59 David Dudley wrote:
> What does the +d option in the sequencer do for you?

Looking at the source code for both the compiler and the runtime, absolutely 
nothing (other than to be passed into the generated program so it can be 
printed by seqShow).

> What I was hoping for was a way to tell what channels connected, in
> order to determine what ones didn't make a connection.

If you give your compiled sequence program a leading option -s it will start 
an iocshell for you after starting the sequencer, and you can then use the 
various seq* tools to debug the program.  If you *don't* specify -s and look 
at it with ps you'll see that it actually immediately becomes a zombie, 
because it exits the main thread while leaving all the other threads to run.

> Also, according to the docs, to stop a Unix sequencer program you do
> 'kill -TERM', but the only way I've been able to kill the things is to
> do a 'kill -KILL'.  Is this something wrong, or just a documentation
> oversight?

I don't know how signals get delivered to threads (does this behavior of 
signals vary between different Unixen?) but the non-existence of the main 
thread probably explains why you can't use 'kill -TERM' on the process.  
Maybe the code should be registering a signal handler in another thread to 
cause a controlled shutdown, or maybe it should do something other than 
calling epicsThreadExitMain()?

I don't know whether SLAC feel they "own" the sequencer any more or not, but 
if someone else wanted to take over maintenance or even just fix one or two 
things like this I'm sure there wouldn't be any objections.

> Finally, sequencer 2.0.12 programs, under both Linux and NetBSD, seem
> to have problems with re-connecting to a channel when the channel
> disappears, and comes back on.  The first time, it works most of the
> time, but the second, it will almost always crash.

I don't see that happening on my Linux system (Fedora 8 on Linux-x86_64 SMP) 
running R3.14.10-pre (current CVS); I can stop and start the IOC as many 
times as I like and the sncProgram always reconnects.  However Jeff has 
committed a few changes to CA recently that might have something to do with 
this problem.

You might want to try running base/src/libCom/test/O.<arch>/blockingSockTest 
on your NetBSD system, just to make sure that the socket shutdown mechanism 
is correct for that OS; I could see this as a possible cause of such 
problems.

HTH,

- Andrew
-- 
Talk is cheap. Show me the code. -- Linus Torvalds

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System