Hello Andrew,
Thank, you for your explanation.
Unfortunately this behavior bites me now. After upgrading to a new OS
and thus Tcl/Tk version, it turned out that monitors in our EPICS-Tcl
interface did not work any more. This is because Tcl now can be compiled
"thread aware" (which has been done by the distributor) and refuses to
accept commands that come from a different thread.
Somehow I now have to get the Tcl callbacks back into the context of the
main thread which runs an event loop that polls the ca library.
It would be nice to have the old 3.13 style behavior back where
everything that interacts with the user process is the same (main)
thread, even if CA uses multiple threads internally.
Dirk
Andrew Johnson wrote:
On Monday 28 March 2011 09:57:27 Dirk Zimoch wrote:
If I create a CA client context with
ca_context_create (ca_disable_preemptive_callback);
or, what is the same, with
ca_task_initialize();
in which thread context will then the callback handlers be called? Is it
in the context of the thread that calls ca_pend_io() or still in the
context of a separate thread? How was it implemented in 3.13?
In 3.14 the CA client callbacks are *always* made in the context of an
internal CA thread, and never of the thread that called ca_pend_io() /
ca_pend_event(). If you use the above calls to initialize the library
the callbacks are only ever called while the other thread is still
executing the ca_pend_*() library routine, so you do not have to
include mutexes in your code.
It occurs to me that there *could* be some circumstances where that's
not strictly true, if the ca_pend_* thread responds to a signal, but
that would be fairly unusual and would probably break the rules for
signal handlers anyway.
In 3.13 the callbacks were made from the thread that called
ca_pend_*(), CA was not multi-threaded internally and did all its I/O
using the select() OS call. The CAS still uses this approach.
- Andrew
