Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 21 Apr 2011 16:54:11 -0600

> 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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System