EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  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  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: PyEpics and Python threads
From: Andrew Johnson <[email protected]>
To: Matt Newville <[email protected]>
Cc: "Vigder, Mark" <[email protected]>, [email protected]
Date: Thu, 21 Apr 2011 16:39:18 -0500
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 Jeff Hill
References:
PyEpics and Python threads Vigder, Mark
Re: PyEpics and Python threads Andrew Johnson
Re: PyEpics and Python threads Matt Newville

Navigate by Date:
Prev: RE: Handling of String Array in CaChannel library Wang Xiaoqiang
Next: RE: PyEpics and Python threads Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: PyEpics and Python threads Matt Newville
Next: RE: PyEpics and Python threads Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·