Experimental Physics and Industrial Control System
> However unless you use the epicsThread routines in libCom
> to create that thread I don't believe it will have any way
> to clean up the context again when that thread exits
The R3.14 ca library, will implicitly create a ca context for the thread
that does not call ca_create_context before it uses ca functions, but in
fact it will not implicitly destroy that context when the thread exits. That
step must be performed manually, by calling ca_destroy_context. This
behavior is invariant of whether the thread was created by the epicsThread
routines or not.
BTW: The implicit creation of a ca context is a side effect of the library
API's remaining backwards compatible with the original single threaded,
single context, implementation.
It's hard to guess if there will ever be a valid need for multiple contexts
in one python program, but perhaps it would be a mistake to preclude that
possibility. Multiple contexts are used in the IOC, for example, to maintain
independence between the database ca links and the sequencer ca variables.
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Andrew Johnson
> Sent: Thursday, April 21, 2011 3:39 PM
> To: Matt Newville
> Cc: Vigder, Mark; [email protected]
> Subject: Re: PyEpics and Python threads
>
> Hi Matt,
>
> On Thursday 21 April 2011 15:17:59 Matt Newville wrote:
> >
> > I find that if I create channels inside Python threads they do have
> > new contexts (that is other than the initial one), even without
> > asking. Doing
> > ca_create_context(); create-and-use-channels ; ca_context_destroy()
> > within a thread seems to work fine.
>
> CA will automatically create a new context if it finds that the thread
> it's
> running in doesn't have one already defined. However unless you use the
> epicsThread routines in libCom to create that thread I don't believe it
> will
> have any way to clean up the context again when that thread exits, so
> wrapping
> the create-and-use-channels code with ca_create_context() and
> ca_context_destroy() like you show above is probably necessary unless the
> process is short-lived or about to die anyway.
>
> > In order to have all processing done in one context, I have to
> > explicitly get the initial context in the main thread, and pass this
> > into each thread. That seems like extra work for the user. If
> > that's the recommendation, would it be reasonable to have ca.py make
> > sure to attach to the initial context (if needed) prior to any
> > processing?
>
> That's what I'm suggesting; you would run ca_create_context() once in the
> PyEpics library initialization and store the value from
> ca_current_context()
> into a global or module variable. The tricky thing is that for
> performance
> reasons you'd rather not have to check whether the context is set for the
> current thread (or explicitly reattach to the main context) every time
> you
> make a CA call. That's where Mark's suggestion of sub-classing the
> python
> threading.Thread class might help, in that it would call
> ca_attach_context()
> once at thread start-up and you'd never need to worry about it again.
> However
> anyone who doesn't use your thread creation code could end up creating a
> new
> CA context and getting weird behavior, so you'd need to document that
> issue
> and provide them with a way to attach other threads to your shared
> context
> anyway.
>
> > Is there a use-case for multiple contexts on the client side?
>
> Very rarely, such that I think you could ignore the possibility and force
> all
> threads into a single shared context. However the nice thing about
> relying on
> thread start-up (or the user's code) to do the attach is that it should
> run
> slightly faster and still permit user code to create a new context and
> attach
> specific threads to that instead of the main context if the developer
> wants to
> do that.
>
> HTH,
>
> - Andrew
> --
> An error is only a mistake if you don't learn from it.
> When you learn something from it, it becomes a lesson.
- Replies:
- Re: PyEpics and Python threads Andrew Johnson
- References:
- PyEpics and Python threads Vigder, Mark
- Re: PyEpics and Python threads Andrew Johnson
- Re: PyEpics and Python threads Matt Newville
- Re: PyEpics and Python threads Andrew Johnson
- Navigate by Date:
- Prev:
Re: PyEpics and Python threads Andrew Johnson
- Next:
RE: Handling of String Array in CaChannel library Jeff Hill
- 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: PyEpics and Python threads Andrew Johnson
- Next:
Re: PyEpics and Python threads Andrew Johnson
- 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