Re: EPICS Python Question

[Matt Newville <newville@cars.uchicago.edu>]

Hi Michael,

Sorry for coming late to this conversation.

On Tue, Sep 30, 2014 at 9:38 AM, Michael Davidsaver <mdavidsaver@bnl.gov> wrote:

>> For cothread, Yes, the only way to have multiple threads is to call its own Spawn method.

Ok, this is not true.  There is *nothing* about cothread which prevents
additional OS threads from being started.

The restriction is the the *first* thread to call "import cothread"
becomes special, and is the only one which can preform CA operations
(and other cooperative things).  Care must be taken to avoid blocking
syscalls on this thread.

Pyepics supports threading, without these concerns.  Pyepics.PVs created in a new thread automatically use the initial CA context (calling ca_attach_context()  to the original context).  For experts who may not want this feature, the ca module gives more a complete, low-level, and C-like interface.

It is true that CA preemptive callbacks can mean that a CA thread that might have a conflict
with another C++ loop, say from a GUI toolkit.  That is a GUI event calling an epics thread or an epics asynchronous callback wanting to update a GUI.  This can definitely happen with the wx GUI toolkit, but the problem is not isolated to wx+CA but wx+Anything.  These problems can be avoided (and wx-specific tools are included with pyepics to help avoid this situation), and wx GUIs work fine with pyepics (I use them pretty much full time). FWIW, not all C++ event-loop toolkits have this issue -- Qt handles the situation better.

This past spring I spent some time working to eliminate the special
thread restriction to make it easier to accommodate 3rd party libraries.
 The work in progress can be found here:

https://github.com/mdavidsaver/cothread/commits/master

This allows CA and other cooperative tasks in multiple OS threads.  It
still isn't finalized, and any input would be greatly appreciated.

I'm very happy that pyepics needs no such effort, and threads work with 3rd party libraries.

> Right, and since it's hard to update third-party libraries which
already use the original Python threading to cothreads, that was a
blocker for me.

Some other work I did was to enhance the cothreads sockets wrapper to
the point that many of the Python standard library modules now work
transparently with cothread.  I've tested the http client/server and
SMTP client.

This has been merged, but not released.

 
If I needed to put in much effort to get standard libraries to work, I would definitely question the approach.   Of course, a CA client must work with web and mail clients!  For CA+wx, I did question the need for having to include special code, and found that the wx library was the culprit that needed special code.

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.

Cheers,

--Matt Newville