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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: SNL sequencer apparently losing connection to underlying network |
From: | Matt Newville <[email protected]> |
To: | Benjamin Franksen <[email protected]> |
Cc: | Kevin Meyer <[email protected]>, Tech-talk <[email protected]> |
Date: | Thu, 1 Dec 2016 14:41:29 -0600 |
On 01.12.2016 10:15, Kevin Meyer wrote:
>>>> I assume that all the SNL code is executed within some 'main'
>>>> thread of the sequencer. Maybe the call out to python hangs, so
>>>> the core SNL thread is stuck and no longer updating anything.
>>
>> No this is not the case as you found out. A separate thread is
>> spawned for each state set.
>>
>> Does you Python program use CA? If yes, then I have a theory: the
>> problem comes from the Python program trying to create a CA client
>> context, but ending up re-using the one from the state thread. And
>> when the Python ends, the context is destroyed, effectively
>> disabling the state thread's CA capability.
>
> Yes, the Python program uses pyEpics's epics.caget, but there are
> some complications here:
> 1. The Python context is created in the
> sequencer's global entry block and shut down in the global exit block
> (the PyObject's are initialised there and re-used in subsequent State
> entry calls).
Which method are you using to call Python functions from C?
What happens if you do _not_ shut down the client context? (It may be
necessary to call ca_detach_context to avoid that being done
automatically by some finalizer on the Python side.)
> 2. How would the Python process EPICS get ahold of the
> calling-sequencer's C EPICS context?
I don't know how the Python binding works, but from C you would call
ca_current_context[1] to get the client context and ca_detach_context[2]
when you are done -- the last is so that the context is NOT destroyed
when the Python program exits.
> 3. The susceptible sequencer still works fine if I stop one of the
> *other* sequencers (that updates two of the PVs) used, above.
I have no idea how to explain this.
>> To test this, replace the Python program with a very simple program
>> that does not import any CA stuff. If the problem persists this
>> means my guess was wrong.
>
> When testing I could get the sequencer to work by commenting out only
> *some* (and leaving in others) of the epics.caget(xxx) calls.
Very strange. Does it matter which caget calls you throw out?
It may be important to know that the sequencer uses
ca_enable_preemptive_callback when creating the context (which is, BTW,
shared by all state sets in all sequencer programs on the same IOC).
This means that the CA client library executes callbacks from a separate
(internal) thread, preempting the thread that makes the CA calls.
Perhaps the Python CA binding cannot cope with this? You could contact
the authors of the Python CA binding to find out more about that...