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  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Invitation to test cothread.catools release candidate
From: Matt Newville <newville@cars.uchicago.edu>
To: michael.abbott@diamond.ac.uk
Cc: tech-talk@aps.anl.gov
Date: Fri, 16 Mar 2012 06:36:21 -0500
Hi Michael,

Thanks, I think I'm starting to understand the design decisions that
went into cothread.catools, while still being satisfied with the ones
in pyepics.

On Thu, Mar 15, 2012 at 4:36 AM,  <michael.abbott@diamond.ac.uk> wrote:
> Hi Matt,
>
> I won't have time for a considered reply for a bit; in particular, I think I'll have to actually write an proper implementation of
> catools using callbacks for a really considered reply (as I said before, the error handling is particularly troublesome as the
> flow of control gets scattered), and that's got to wait its turn, maybe a suitable soggy day.

Hmm, I can sort of see your point that handling error that might occur
in callback code is difficult.  To be honest, I do ignore the issue --
errors in callbacks are raised, but if not caught in the callback code
itself, messages are sent to stdout/stderr and the callback ends, but
processing continues.   I'm sure it could be done better, but I tend
to make callback functions do very little heavy lifting, and I rely on
tests.

But, you have to be using some callbacks, no?   Your get_many()
example earlier was doing a get-callback, and you have a camonitor()
function.  Is it that you're relying on using
non-preemptive-callbacks, and capture exceptions per thread?    Your
code being GPL, I haven't looked at it, so you might have to put up
with such silly questions.

> However I think I can sensibly respond to your conclusion straight away.
>
> From: matt.newville@gmail.com [mailto:matt.newville@gmail.com]
>
>> So, if I understand correctly, a principle motivation is that you
>> prefer many threads over relying on pre-emptive callbacks.   With that
>> preference, thread "weight" becomes a serious issue, so much so that
>> you cannot rely on standard python threads.  Is that a fair
>> assessment?
>
> Not unfair, though historically slightly backwards: an equally strong motivation is avoiding event callbacks at an inconvenient time.  Or, to reiterate an earlier point, cothread allows the naive, lazy or busy programmer to avoid having to worry about thread synchronisation and locking issues, because diversion of flow of control can only happen at well defined and easy to understand places.  I suspect this is a bigger win than most people realise.
>
> I've just checked with James who did the original work that led up to cothread and cothread.catools and the history is rather interesting: it turns out that the original motivation for using coroutines (or "greenlets" as the library we used called them) was to avoid problems with Qt3 caused by triggering Qt operations from the wrong thread, and this problem was encountered before working on channel access bindings.  In other words, coroutines were introduced precisely to avoid a thread synchronisation problem with Qt.

That makes it seem as if cothread has very little to do with Channel
Access.   Given this motivation, wouldn't cothread be useful for other
code where one would need to use threads from Python?

Anyway, is this required with Qt4?  I've done very little with PyQt,
but pyepics seemed to work with it rather easily in initial tests.

> As for callback driven versus thread driven code, yes, I am arguing that threaded code is clearer, but it does seem that more examples are needed.

Needing to maintain specialized threading C code is a high cost.

Cheers,

--Matt Newville


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
RE: 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

Navigate by Date:
Prev: RE: Synchronising CA shut down michael.abbott
Next: RE: Synchronising CA shut down Hill, Jeffrey O
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: Invitation to test cothread.catools release candidate michael.abbott
Next: Here is a Message Szalata, Zenon M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
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 ·