Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Enabling debug output from Java
09-10-2013, 02:22 PM
Post: #11
RE: Enabling debug output from Java
I am making good progress with this and I have something working. I'd appreciate a tiny bit of C++ education to confirm that my code is OK.

The constructor for InitialisationParams::InitialisationParams doesn't initialise all the callback functor members. For example, it doesn't initialise iAsyncBeginHandler. The value of this member is checked by an if test in InvocationManager::Invoke, so I presume that it is somehow getting initialised implicitly to a "null" value. What is the piece of C++ magic that makes this happen?
Find all posts by this user
09-10-2013, 02:36 PM
Post: #12
RE: Enabling debug output from Java
(09-10-2013 02:22 PM)simoncn Wrote:  I am making good progress with this and I have something working. I'd appreciate a tiny bit of C++ education to confirm that my code is OK.

The constructor for InitialisationParams::InitialisationParams doesn't initialise all the callback functor members. For example, it doesn't initialise iAsyncBeginHandler. The value of this member is checked by an if test in InvocationManager::Invoke, so I presume that it is somehow getting initialised implicitly to a "null" value. What is the piece of C++ magic that makes this happen?

The default constructor is run for any member not explicitly initialised in the initialiser list. The default constructor for Functor ensures that operator() will return false (i.e. the test if (seemingly_uninitialised_functor) will fail)
Find all posts by this user
10-10-2013, 11:55 AM
Post: #13
RE: Enabling debug output from Java
(09-10-2013 02:36 PM)simonc Wrote:  The default constructor is run for any member not explicitly initialised in the initialiser list. The default constructor for Functor ensures that operator() will return false (i.e. the test if (seemingly_uninitialised_functor) will fail)

Thanks for explaining this. I've completed the proposed patch and I'm attaching it to this post.

The following files are changed:

OpenHome\Thread.cpp
OpenHome\Net\OhNet.cpp
OpenHome\Net\OhNet.h
OpenHome\Net\Bindings\C\OhNetC.cpp
OpenHome\Net\Bindings\C\OhNet.h
OpenHome\Net\Bindings\Java\InitParams.c
OpenHome\Net\Bindings\Java\InitParams.h
OpenHome\Net\Bindings\Java\org\openhome\net\core\InitParams.java

and the following file is added:

OpenHome\Net\Bindings\Java\org\openhome\net\core\IThreadExitListener.java

The changes to the ohNet core and the C bindings are straightforward and follow the pattern of the existing callbacks.

The changes to the Java bindings are in three parts:

1) When the InitParams object is created, the Java bindings automatically register a thread exit callback with ohNet and use this callback to detach the exiting thread from the JVM.

2) A new Java API is added to the InitParams Java class to allow the Java application to optionally register an application-level thread exit handler. If this handler has been registered by the application, the Java bindings will call this handler immediately before detaching the thread from the JVM. This gives the application an opportunity to clean up any resources that it might have associated with the exiting thread.

3) I noticed that the existing Java bindings code for the log output and fatal error handlers would leak global references if the application replaces these handlers with a new value, so I have added code to the InitParams.setLogOutput and InitParams.setFatalErrorHandler Java methods to delete global references that are no longer needed. The corresponding situation with replacing the application's thread exit handler is handled in the new code in InitParams.c.

I have tested these changes on Windows and Linux and I have confirmed that they work as expected. Please let me know if you have any questions about the changes.


Attached File(s)
.zip  threadexit.zip (Size: 5.05 KB / Downloads: 1)
Find all posts by this user
10-10-2013, 03:30 PM (This post was last modified: 10-10-2013 03:30 PM by simonc.)
Post: #14
RE: Enabling debug output from Java
(10-10-2013 11:55 AM)simoncn Wrote:  Thanks for explaining this. I've completed the proposed patch and I'm attaching it to this post.

Thanks. I've committed this now so it'll hopefully be available to you this evening.

Note that while everything in your patch was good, the full set of changes turned out to be a fair bit larger. Some basic tests don't store InitParams; allowing for this in thread exit required that Env::InitParams() and its 80ish callers had to change also.
Find all posts by this user
10-10-2013, 07:59 PM
Post: #15
RE: Enabling debug output from Java
(10-10-2013 03:30 PM)simonc Wrote:  Thanks. I've committed this now so it'll hopefully be available to you this evening.

Note that while everything in your patch was good, the full set of changes turned out to be a fair bit larger. Some basic tests don't store InitParams; allowing for this in thread exit required that Env::InitParams() and its 80ish callers had to change also.

Thanks for doing this so quickly. I've downloaded the tag and it seems to be working well.

I'm sorry for overlooking the InitParams issue. Is there a reason why something like this code in (the previous version of) CallFatalErrorHandler couldn't have been used?

Code:
static void CallFatalErrorHandler(const char* aMsg)
{
    if (gEnv == NULL) {
        Os::ConsoleWrite(aMsg);
    }
    else {
        FunctorMsg& handler = gEnv->InitParams().FatalErrorHandler();
        handler(aMsg);
    }
}
Find all posts by this user
11-10-2013, 07:56 AM (This post was last modified: 11-10-2013 08:05 AM by simonc.)
Post: #16
RE: Enabling debug output from Java
(10-10-2013 07:59 PM)simoncn Wrote:  I'm sorry for overlooking the InitParams issue. Is there a reason why something like this code in (the previous version of) CallFatalErrorHandler couldn't have been used?

It turned out that code was wrong. gEnv is set regardless of whether InitParams is available. I've reworked that function in the same commit.
Find all posts by this user
11-10-2013, 11:32 AM
Post: #17
RE: Enabling debug output from Java
(11-10-2013 07:56 AM)simonc Wrote:  It turned out that code was wrong. gEnv is set regardless of whether InitParams is available. I've reworked that function in the same commit.

OK, all is clear now. It was unfortunate that I chose to copy the if test for calling the thread exit handler from that code. Sad
Find all posts by this user


Forum Jump: