Matt
I did exactly as you suggested below. I assumed that the exception
being returned was a mistake. I'll pull the latest version with
the fix.
Another option for making the code more "plain looking" is to
use a single CA context and subclass Python's threading.Thread.
This subclass can be used for creating threads in PyEpics and
the subclass could switch to the single context in use. This
of course only works if there is a single context for the
application.
This is the first time I've had to deal with CA contexts, and
I must admit I don't understand them yet - why they exist,
when they get switched, or if one might want to have multiple
contexts with PV's defined within different contexts. Time to
hit the manuals.
Mark
On April 20, 2011 10:36 PM Matt Newville wrote
>I think there is a mistake in ca.py, as
>ca.attach_context(context) raises an exception if the return value
>from ca_attach_context() is not ECA_ISATTACHED (I think I read the doc
>incorrectly -- I get ECA_NORMAL). I pushed the change to ca.py to run
>PySEVCHK expecting expect ECA_NORMAL instead of ECA_ISATTACHED to
>github. Ignoring that bug for now, attaching to the existing context
>like this does work:
>
>#
>import time, epics, threading
>
>def threaded_putwait(pv, context, value):
> "put-with-wait for calling in a thread"
> t0 = time.time()
> try:
> epics.ca.attach_context(context)
> except:
> pass
> pv.put(value, wait=True, timeout=10.0)
> print ' - threaded_putwait done (%.3f sec)' % (time.time()-t0)
>
>if __name__ == '__main__':
> pvname = 'XXX.VAL'
> target = 10
>
> pv = epics.PV(pvname)
> pv.put(-target, wait=True)
> context = epics.ca.current_context()
>
> th = threading.Thread(target=threaded_putwait,
> args=(pv, context, target))
> th.start()
> th.join()
> print 'All Done.'
>
>Mark, is that approximately what you found as well?
>
>Perhaps it would be better for a PV to save its context at creation,
>and automatically know to switch to its context before doing any work?
> That would make the saving and attaching of the context in the above
>script unnecessary, so that "plain looking" code could more easily be
>made multi-threaded without having to worry about contexts. I'm not
>sure what the negative consequences of that would be.
>
>--Matt Newville
>
- Replies:
- Re: PyEpics and Python threads Matt Newville
- References:
- PyEpics and Python threads Vigder, Mark
- Re: PyEpics and Python threads Matt Newville
- Re: PyEpics and Python threads Andrew Johnson
- RE: PyEpics and Python threads Vigder, Mark
- Re: PyEpics and Python threads Matt Newville
- Navigate by Date:
- Prev:
RE: shell command arguments limitation? Jim Chen
- Next:
Re: EPICS Base v3.14.12.1-rc1 compilation error Eric Norum
- 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 Matt Newville
- 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
|