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