Experimental Physics and Industrial Control System
Hi Michael,
On Mon, Oct 5, 2009 at 3:12 AM, Michael Abbott
<[email protected]> wrote:
>> For an array of doubles (DBR_FLOAT,DBR_DOUBLE) or ints
>> (DBR_SHORT,DBR_LONG), automatically converting that to a numpy array of
>> the appropriate "dtype" makes perfect sense.
>
> This can in fact be done for all DBR types, even DBR_STRING, though a
> little care is needed in this last case -- these all fit cleanly into
> numpy types and memory layout. So cothread.catools does exactly this for
> all caget and camonitor types.
I'm not sure that a numpy character array is the most natural fit for
a DBR_CHAR waveform, though it might be a good way to store byte
arrays. I often use DBR_CHAR waveforms for long strings, and they
easily appear as strings in MEDM windows, at least for me.
> This funny business of whether a string is a DBR_STRING or a DBR_CHAR
> array is an interesting bit of overloading; think any API needs special
> direction for this.
It is probably best to have user-selectable options for how to convert
array/waveform data into python objects.
>> I guess it's just so easy to roll owns one interface that there is very
>> little incentive to use someone else's code even if it is available and
>> documented. Coming to a common solution would be nice.
>
> Aye. I don't really know how to proceed except by discussing specifics.
>
> I think the ctypes and dbr handling of cothread.catools, specifically the
> files dbr.py and cadef.py, can be used elsewhere with little argument.
> The question of whether cothreads are valuable is quite a separate
> conversation!
My impression is that using ctypes has significant advantages over
SWIG or straight C extension code. I'm less sure about the cothread
and greenlet parts. I do have some other thoughts on cothreads, but
I'll save those for later.
> This isn't really a problem, as the Global Interpreter Lock is
> periodically freed by the intepreter (every so many Python opcodes, can't
> remember how many), so all that's really needed is that a function calling
> into the Python interpreter takes the GIL.
> In other wrods, a background CA polling thread *can* acquire and release
> the GIL, that's what it's there for!
What confuses me is *how* the background CA polling thread (with no
direct communication with the main Python thread) knows to acquire and
release the GIL. Maybe because there is one Python interpreter held
globally for the process this can happen?? I thought that only
threads launched from Python could do that --perhaps that's wrong.
>> For interactive shell work, I rarely use callbacks at all. Do you use
>> callbacks here? I do like your idea of adding a polling hook into the
>> readline library so that one did not need to explicitly poll from the
>> shell, but that's the same as enabling preemptive callbacks. Again,
>> maybe I am misunderstanding something here. Please correct me if I am
>> wrong.
>
> We need to distinguish with care between preemtive and non-preemptive
> callbacks. In particular I would not describe callbacks from the readline
> hook as "preemptive", as they only occur at a well defined and predictable
> point (when the intepreter is waiting for keyboard input from the user).
I agree with you: polling in a readline hook is not using preemptive
callback. Personally, I don't see much to be gained with preemptive
callbacks, as polling can be buried in the interface layer.
>> The strategy I take with wxPython is to have a
>> python callback for each PV that simply notes that the PV has changed
>> (and caches the value), and then set up a Timer loop() for the GUI
>> that effectively does
>> ca_pend_event()
>> react_to_changes()
>
> This is not so dissimilar to what cothread.catools does. If you set up a
> monitor with
> camonitor(pv_name, callback)
> then callback is *not* processed in the context of the CA callback, but is
> instead processed on a dedicated cothread. Instead CA callbacks simply
> place updates on a queue which is then automatically processed.
>
> I am wondering whether to let these callback happen on a separate thread:
> I guess I'll need to do some timing tests, because that'd be the only
> compelling reason to use asynchronous callbacks instead of the current
> polling mechanism.
I'd guess that timing tests would show little or no advantage to using
asynchronous callbacks or using threading at all. I'd be happy to be
proven wrong on this.
I could believe that using coroutines and greenlets is a better
approach to threads. Personally, I would have thought that using
real sub-processes (And so multiple CPUs) was actually the best way to
improve performance and reliability.
> Hum. Think this has got a trifle overlong!
Perhaps this topic (how to build a better Python CA interface) is a
bit too specialized and/or off-topic for Tech-Talk, and we should move
the conversation somewhere else? A wiki? A separate mailing list?
As I've said before, I would be interested in collaborating on an
improved CA Python interface and standardizing interfaces to other
libraries (numpy, matplotlib, GUI wrappers, etc) and applications.
Cheers,
--Matt Newville <newville at cars.uchicago.edu>
- References:
- Re: EPICS Python client application survey Matt Newville
- Re: EPICS Python client application survey Matthieu Bec
- Re: EPICS Python client application survey Matt Newville
- Re: EPICS Python client application survey Michael Abbott
- Navigate by Date:
- Prev:
Re: Channel access and ca_element_count Andrew Johnson
- Next:
Re: state notation code flags Benjamin Franksen
- 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 Michael Abbott
- 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