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: [email protected]
Cc: "Vigder, Mark" <[email protected]>
Date: Thu, 21 Apr 2011 14:31:05 -0500
Hi Matt,

On Thursday 21 April 2011 13:22:13 Matt Newville wrote:
> Subclassing threads seems like more work to me too.  The change to PV
> to save its context and then make sure that is used for put() and
> get() is just a couple lines of code -- I can check that the context
> is correct in the same routine used to make sure the channel is
> connected.  And that does allow PVs created in the main thread to be
> used in child thread.  Creating PVs in a non-main thread still
> requires creating a new context.

Can you explain what you meant by that last sentence, as I think I disagree 
with it (rather than creating a new context it would be better to attach to a 
common context if one already exists).

If you're going to integrate threading support into PyEpics I would encourage 
you to try to use a model that by default shares a single CA context between 
all threads, and maybe allow an application to create a separate CA context 
for a particular group of threads if a developer decides that is necessary.  
As I think I said before the majority of applications will want to share a 
single context so if possible the "attach" behavior should be provided 
invisibly to the user.

There might be cases where the application developer wants separate contexts, 
but the need for that is really rare, so you could leave it out — I haven't 
implemented it in my CA-Perl5 layer, but I haven't tried using that with 
multiple threads yet either.

To help Mark's understanding, each separate CA context acts just like its own 
CA client process, thus results in separate TCP sockets being opened to any 
IOC it connects to, and will also duplicate various internal CA threads.  The 
main use for multiple CA contexts within a single process is probably inside 
the IOC, where there are separate contexts for the Sequencer, Access Security 
and dbCa links, so that each subsystem can run completely independently of the 
others.

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 Matt Newville
References:
PyEpics and Python threads Vigder, Mark
RE: PyEpics and Python threads Vigder, Mark
Re: PyEpics and Python threads Matt Newville

Navigate by Date:
Prev: Re: shell command arguments limitation? Daron Chabot
Next: Memory bank swap feature for SIS3301? Frank Hoeflich
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 Matt Newville
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 ·