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

Subject: RE: EPICS Python client application survey
From: <[email protected]>
To: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>
Date: Wed, 30 Sep 2009 16:31:46 +0100
I'm going to take the position of explaining how cothread.catools addresses Matt's points -- I very much agree with most of what Matt is saying, but I think that cothread already addresses most of his points!  Forgive me for being so partisan about my own implementation, it's hard not to be...

From: [email protected] 
> Hi Noboru, Wang, John, Michael, all,
> 
> As I've said before, I would be happy to collaborate to come up with a
> more uniform approach to using CA with Python.
> I agree with Noboru that a two-tier approach is needed.  I'm not so
> sure that a 'thin wrapper to all of ca' is crucial.

I quite agree.  However, take a look at cadef.py and dbr.py: these two files use ctypes to wrap precisely those parts of CA needed to implement catools (there are a few extra lingering definitions remaining from earlier experiements, think I might clean those out for the next release).  ctypes is remarkably powerful at this sort of task. 

> For example, I don't see significant advantages to having all the C CA
> types (DBR_SHORT, DBR_INT, DBR_LONG, etc) exposed to Python at all, as
> Python does not distinguish these types, and the difference never
> needs to be exposed to the Python programmer.  The DBR_ type for a
> channel is an implementation detail that is important in C, but not in
> Python.  One should be able to create a channel/PV in Python without
> knowing its underlying type.  One should be able to ask for the "extra
> information" in a DBR_***_CTRL type (and possibly _STS, _GR types),
> but I see no advantage to having 'ca.DBR_LONG' existing in Python.  I
> also think there is no point in ever seeing the Channel ID in Python,
> as this should always be inside a Channel or PV object.

Yes.  And further, there are too many DBR_***_ classes; in cothread I've only implemented raw, TIME and CTRL; the rest are rather redundant. 

On the other hand, you do need to be able to specify DBR_ENUM if you want access to the list of enum strings: with cothread you get that with the request:
	caget(pv_name, datatype=DBR_ENUM, format=FORMAT_CTRL).enums

In cothread's dbr.py there are two functions used inside catools.py: value_to_dbr() takes a python value and creates a dbr ready to be passed to ca_array_put[_callback], and dually dbr_to_value(dbr) which takes a dbr and converts it to a Python value (slightly oversimplified, check the code for truth).

> In addition, exposing CA threads to Python is complicated, and simply
> wrapping the C code and telling the Python programmer to deal with the
> problem "just like C" seems like a poor choice to me.  The Python
> Global Interpreter Lock makes using CA with Python threads perilous:
> can a channel/PV in one thread call code in another thread?  Can CA
> threads be used with other threading code (GUIs, for example).
> Perhaps the Cothreads approach or using subprocess is a better
> solution.  I am not sure sure that using preemptive callbacks can
> really work in Python, as it would allow a CA C thread to call a
> Python function when non-CA Python code is running.....  What happens
> if that C thread does not hold the Python GIL?

I think this is all doable, the GIL is well defined, and it isn't necessary to enable asynchronous CA callbacks!  On the other hand, real threads are a little bit futile in Python, and at least older Qt just dies horribly if all calls into it aren't single threaded -- I think this is why I went for coroutines originally.
 
> I also think there are things which are done well at the C level to
> help a Python wrapper that would not be part of a 'thin wrapper':
> automatically fetching enum string names, a simple "put and wait until
> done" method, managing a set of PV connections, and so forth.  These
> may seem like "extras" to a C programmer, but they are not to a Python
> interface.

Actually, "put and wait until done" is easy, with cothread this is just
	caput(pv_name, new_value, wait=True)
If you want to go ahead and do something else while waiting for this to complete, just spawn another cothread!

Of course the implementation is interesting, but then so is the implementation of any CA operation, as we always have to wait for a connection.

The cothread implementation of this function is, in caricature:

	done = cothread.Event()
	ca_array_put_callback(
	    value_to_dbr(value), (lambda args: args.usr.Signal()), done)
	done.Wait()

(There are unimportant lies here, but inspecting the code will make things clearer.)
 
> Finally, I think documentation is crucial, and find it somewhat
> lacking in several of the existing interfaces.
> 
> Again, I'd be happy to collaborate on these to make a better and more
> uniform python interface.  But I do think there are important details
> to be worked out beyond exposing a low-level interface to the C
> library.

I wonder if a non-cothreaded implementation could be fitted underneath cothread's catools.py.  The main problem is the very free use of spawning, signalling and waiting operations in catools.py; I think it would be very hard to implement these efficiently without some form of coroutine mechanism ... but I haven't looked at this very hard.
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 


Replies:
Re: EPICS Python client application survey Shen, Guobao
References:
Re: EPICS Python client application survey Matt Newville

Navigate by Date:
Prev: Re: EPICS Python client application survey Matt Newville
Next: RE: EPICS Python client application survey michael.abbott
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS Python client application survey Matt Newville
Next: Re: EPICS Python client application survey Shen, Guobao
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·