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
<2011>
2012
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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|