Experimental Physics and
Industrial Control System

<[email protected]> · Thu, 2 Oct 2014 07:56:42 +0000

From: [email protected]
> [mailto:[email protected]]
> Sent: 01 October 2014 15:34
> To: [email protected]
> Cc: [email protected]
> Subject: RE: EPICS Python Question
> 
> From: Matt Newville [mailto:[email protected]]
> > Out of curiosity, why not use generators and yield as
> > coroutines or the asyncio module?   I think that using
> > these standard python solutions for coroutines and
> > threads might greatly simplify things for you.

Another key detail: asyncio is Python 3 only.  As it rests so heavily on the use of "yield from" (which has even more consequences than I've mentioned below -- generators and functions can't be treated in the same way, this separation will permeate the entire asyncio library and its users), and as this is a Python 3 only construction, it's not terribly relevant to us.

However, there are probably a lot of ideas and techniques in the event handling that are worth a closer look.  

Probably the biggest drawback of the current implementation of cothread is that it just doesn't work on Windows (this is partly because I'm delighted to have stopped programming on that platform for well over a decade now), and the other reason for this is that the Windows IO event model is completely different from the Posix event model.  At present cothread rests on select (or poll if available) for IO event dispatch, and Windows just won't play right.

I notice also that asyncio compels the user to manage an event loop (oh, the memories of Windows programming come flooding back -- blank them out, blank them out!), cothread works very hard to ensure that users know nothing about this low level detail (it's tucked away inside cothread._Scheduler if anybody cares to look).

In my opinion it's very unwise to throw threads at a problem without understanding the consequences -- the delightful problems that unexpected (and often completely unreproducible) synchronisation errors throw up are an endless distraction.

> One important difference is that any time an asyncio "coroutine" calls
> a function (really a generator) that might wish to suspend it will have
> to use the "yield from" syntax.  This means that
> 
> 	x = caget(pv)
> 	caput(pv, f(x))
> 
> would have to be rewritten as
> 
> 	x = yield from caget(pv)
> 	yield from caput(pv, f(x))
> 
> I suppose this has the advantage of making possible suspension points
> clearer, but otherwise it looks pretty unsightly to me.  In particular,
> this means that *any* Python that wishes to perform channel access
> suddenly needs to transform itself into a generator, which affects how
> it is called, and so on.
> 
> However, asyncio clearly merits a much closer look.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System