EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: bug report
From: Andrew Johnson <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'Matej Sekoranja'" <[email protected]>, "'Ernest L. Williams Jr.'" <[email protected]>, "'Thomas Pelaia II'" <[email protected]>, "'Matej Sekoranja'" <[email protected]>, "'Kasemir, Kay'" <[email protected]>, [email protected], EPICS core-talk <[email protected]>
Date: Thu, 19 Oct 2006 10:42:10 -0500
Jeff Hill wrote:
I had a quick look at the JNI library and I also don’t see any obvious solution that does not require modifications to EPICS base.

Perhaps the next question is whether the proposed interface registering for thread begin / exit callbacks should be implemented in (A) the CA client library or (B) alternatively in epicsThread (see epicsThread.h).

I worry that it’s only a matter of time until we have more requests to tightly integrate the Java VM within processes that might be running EPICS. Perhaps it’s not a bad idea to, only when the Java VM is embedded in a process that is also running EPICS, go with (B) and always bind the VM to each and every EPICS thread that gets started. Since this would occur only when the thread starts and stops presumably the overhead would be minimal.

Furthermore, if we implement the epicsThread start / exit hook interface I can also see a low overhead option using thread private variables that:

O attaches to the VM from within the JNI callback only the first time that a JNI callback gets called by EPICS for a particular thread

O in the global epicsThread exit hook un-registers the current thread with the VM only if it is currently registered with the vm

I could provide a pseudo code implementation for the 2^nd option if you are interested.

I am thinking that the proposed interface belongs in epicsThread.

What do you think?

Jeff

------------------------------------------------------------------------

*From:* Matej Sekoranja [mailto:[email protected]]
*Sent:* Wednesday, October 18, 2006 12:03 PM
*To:* Jeff Hill
*Cc:* Ernest L. Williams Jr.; Thomas Pelaia II; Matej Sekoranja; Kasemir, Kay; [email protected]; Andrew Johnson
*Subject:* Re: bug report

Hi,

On 10/17/06, Jeff Hill wrote:

Even if the memory leak is fixed by Sun, it would be desirable to fix the JNI code so that it doesn't need to register/unregister the thread (apparently a very high overhead call) from within every subscription update callback? If there isn't a solution in the java support then perhaps one possibility would be to provide a registration interface in the ca client library specifying a user callback that gets run in the context of a CA thread when it (the thread) starts and when it exists. We might then register / unregister the thread with java from that call back.

I agree that in principle, the right place to put this would be in the epicsThread implementation. Looking at the current code we will have to add the hook calls to each of the src/libCom/osi/os/*/osdThread.c files, but we appear to have suitable wrapper functions in all 4 implementations that will allow us to do that.

I'd like to see a firm proposal for the API, including an indication of what is expected to happen if a callback gets registered after several threads have already been created. We should already have sufficient infrastructure to be able to call a hook for each existing thread if we decide that's what we want to happen, but that call would not be from the context of the thread itself, so it might not be a useful thing to do.

I would want to allow more than one hook to be registered at the same time, and for there to be both a C and C++ API for registering hooks.

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger

Navigate by Date:
Prev: RE: Changes for RTEMS on ARM (at91rm9200ek) Jeff Hill
Next: Timetable for R3.14.9? Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Changes for RTEMS on ARM (at91rm9200ek) Jeff Hill
Next: Timetable for R3.14.9? Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·