Experimental Physics and
Sorry for coming late to this conversation.
On Tue, Sep 30, 2014 at 9:38 AM, Michael Davidsaver <firstname.lastname@example.org> wrote:
>> For cothread, Yes, the only way to have multiple threads is to call its own Spawn method.
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
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
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.
|ANJ, 17 Dec 2015||
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·