Subject: |
Re: Invitation to test cothread.catools release candidate |
From: |
Michael Davidsaver <[email protected]> |
To: |
[email protected] |
Date: |
Mon, 12 Mar 2012 19:02:22 -0400 |
Hello Matt,
What initially attracted me to cothread was the simple yet powerful API
of catools. It took me a while to appreciate the cooperative threading
aspect. I think this was mainly because it differs from the OS
threading APIs I was used to. Considered from the prospective of a new
programmer without such a bias, I would agree with Michael Abbott that
it is easier to learn.
On 3/12/2012 12:17 PM, Matt Newville wrote:
...
With Python threads it seems to me that the biggest down side of cothread, that there is only one thread of
execution, has much less impact, as Python only ever executes one thread at a time in the interpreter anyway!
To me, this would seem to have very little to do with Channel Access,
and more to do with python's threading implementation. Is that a fair
characterization? If so, should it be a separate python package,
useful outside of the scope of Channel Access?
(For the audience, what is being referred to is the Global Interpreter Lock)
http://wiki.python.org/moin/GlobalInterpreterLock
...
Coding with callbacks requires a continuation style of programming mixed with threading based events when you need
to resynchronise with the original caller. This is definitely harder to write, particularly when exceptions and
error handling need to be taken into account.
I'm not sure I'm following you here. Concrete examples would be nice.
I don't have any examples showing both ways, mostly because with
cothreads I can happily avoid continuation passing.
There are some related examples from the Twisted library's
inlineCallbacks feature. This is the first concise example I could find:
http://hackedbellini.org/development/writing-asynchronous-python-code-with-twisted-using-inlinecallbacks/
Note that while the syntax and effect are similar, the implementation is
much different (less general, but more portable). It is not saving the
stack, but rather taking advantage of the fact that python generators
are functions with multiple entry points.
...
...
for pvname in list_of_pvnames:
print caget(pvname)
Please consider that catools.caget can accept a list of pvs directly.
R = caget(list_of_pvnames)
This can be combined a FORMAT_* specifier to get metadata as well. Oh,
and it works for a list of PVs with mixed types.
>>> caget(['INJ-TS{EVG-EvtClk}RFFreq-SP', 'LN-RF:PB{Cav}Message-I'],
format=FORMAT_TIME)
[499.68000000000001, 'Socket Error: No route to host']
When I discuss cothread/catools I say that it is deceptively simple in
the best way. It is simple to use when you're starting. Later, when
you need more, you discover that its already there.
Michael Davidsaver
NSLSII Controls Group
Brookhaven National Lab
- References:
- Invitation to test cothread.catools release candidate michael.abbott
- Re: Invitation to test cothread.catools release candidate Matt Newville
- RE: Invitation to test cothread.catools release candidate michael.abbott
- Re: Invitation to test cothread.catools release candidate Matt Newville
- Navigate by Date:
- Prev:
Re: MVME2434-1 Till Straumann
- Next:
RE: SmarAct / SmarPod Emma Shepherd
- 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: Invitation to test cothread.catools release candidate Matt Newville
- Next:
RE: Invitation to test cothread.catools release candidate 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
|