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
- References:
- SEQ tools David Dudley
- Navigate by Date:
- Prev:
Re: SIemens PLCs David Dudley
- Next:
epicsThreadSleep() and epicsThreadSleepQuantum() Mark Rivers
- 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
- Navigate by Thread:
- Prev:
Re: SEQ tools David Dudley
- Next:
EDM font sizes Zhou, Jingchen
- 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
|