Oliver,
No problems. I agree.
Evgueni
On 10/13/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
Hi Evgueni,
Ive taken a look at the patch - it looks fine to me.
My only comment on:
//(*jvm)->DetachCurrentThread(jvm);
is that I believe we need this line to be uncommented to get the correct
beha
Hi Evgueni,
Ive taken a look at the patch - it looks fine to me.
My only comment on:
//(*jvm)->DetachCurrentThread(jvm);
is that I believe we need this line to be uncommented to get the correct
behaviour when running with the IBM VME. As such, I would suggest
uncommenting this line in the Harm
Sorry guys, I've just found different problem at the very same place.
Nik.
On 10/11/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
Nikolay,
From what you said above I conclude that it is TM problem in respect
to how it manages non-daemon threads. Do you agree? If you don't
please start another
Nikolay,
From what you said above I conclude that it is TM problem in respect
to how it manages non-daemon threads. Do you agree? If you don't
please start another thread with appropriate subject. It seems to be
out of current topic.
Evgueni
On 10/11/06, Nikolay Kuznetsov <[EMAIL PROTECTED]>
Evgueni,
On 10/11/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> I have a quick note about detaching current thread. I've filled
> HARMONY-1816 issue about counting non daemon threads. And concerning
> DetachCurrentThread we should either detach it
I don't understand your concern what sh
Nikolay,
On 10/11/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about counting non daemon threads. And concerning
DetachCurrentThread we should either detach it
I don't understand your concern what shoul
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about counting non daemon threads. And concerning
DetachCurrentThread we should either detach it or rewrite
wait_for_all_nondaemon threads to take into account the fact that main
thread is also non daemon.
Nik.
On
Oliver,
I created https://issues.apache.org/jira/browse/HARMONY-1819 with
suggested fix. Please, look at and update it if DetachCurrentThread is
required before DestroyJavaVM for some reason.
Thanks
Evgueni
On 9/22/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
On 9/22/06, Oliver Deakin <[EMAI
On 9/22/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
Tim Ellison wrote:
> Still, it seems strange that you should have to call DetachCurrentThread
> explicitly to get this behavior. I would have expected that
> DestroyJavaVM alone would cause the uncaught exception handler to fire.
> Not all a
Tim Ellison wrote:
Still, it seems strange that you should have to call DetachCurrentThread
explicitly to get this behavior. I would have expected that
DestroyJavaVM alone would cause the uncaught exception handler to fire.
Not all apps that embed the VM will know to make this work-around.
Still, it seems strange that you should have to call DetachCurrentThread
explicitly to get this behavior. I would have expected that
DestroyJavaVM alone would cause the uncaught exception handler to fire.
Not all apps that embed the VM will know to make this work-around.
Regards,
Tim
Oliver De
Evgueni Brevnov wrote:
Oliver,
Yes, I got the same result on RI when starting VM by your simple
launcher. Assume it is OK not to print an error message and stacke
trace of an unhandled exception in JavaDestroyVM(). How about calling
uncaught exception handler? According to the spec it must be ca
Oliver,
Yes, I got the same result on RI when starting VM by your simple
launcher. Assume it is OK not to print an error message and stacke
trace of an unhandled exception in JavaDestroyVM(). How about calling
uncaught exception handler? According to the spec it must be called if
terminating thre
Hi Evgueni,
I wrote a simple launcher [1] that does the following:
1) Calls CreateJavaVM
2) Runs the main method of your Test class below
3) Calls DestroyJavaVM
Note that it does *not* call env->ExceptionDescribe() before destroying
the VM.
I tested this launcher against the RI and J9 and found
Hi All,
I'm almost done with the implementation of Invocation API for DRLVM.
While testing it I ran into a problem when an exception is printed
twice. I created a simple application which just throws an error and
it is not handled by any exception handler:
public class Test {
public static vo
15 matches
Mail list logo
