Re: threads+CNI+SIGINT

Re: threads+CNI+SIGINT

[Oskar Liljeblad]

> > Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
> > it installed in the main thread? If not, how is GC cleanup/finalization
> > done?
> 
> What version of libgcj are you running? 2.95.1 does install a handler for
> SIGINT which can cause problems like you describe. It should be fixed on
> the current cvs version (if you are using libgcj from cvs, can you provide
> a test case that demonstrates the problem?)

I was using egcs 2.96 (2000-03-13 snapshot) and libgcj snapshot from
2000-03-18.
I'll get back to you when I have tried the latest libgcj from CVS.

Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Oskar Liljeblad]

> > Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
> > it installed in the main thread? If not, how is GC cleanup/finalization
> > done?
> 
> What version of libgcj are you running? 2.95.1 does install a handler for
> SIGINT which can cause problems like you describe. It should be fixed on
> the current cvs version (if you are using libgcj from cvs, can you provide
> a test case that demonstrates the problem?)

I was using egcs 2.96 (2000-03-13 snapshot) and libgcj snapshot from
2000-03-18.
I'll get back to you when I have tried the latest libgcj from CVS.

Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Tom Tromey]

Jeff> In a native CNI method, what signal handlers (if any) can I
Jeff> safely install?  Some signals are reserved by boehm-gc and
Jeff> linuxthreads.  Is this documented?  (I know, I'm too
Jeff> lazy/time-crunched to go look for myself.)

This area isn't documented.
You could probably handle any signal that isn't handled by the GC,
LinuxThreads, or by the runtime (the runtime currently handles SIGSEGV,
SIGFPE, and SIGPIPE).

Tom

threads+CNI+SIGINT

[Oskar Liljeblad]

I'm playing with ncurses in Java through CNI. There's a demo program,
called Rain, that I translated. It displays ASCII-art raindrops that
later disappears - like a screen saver.

When I compile and run this java program, and interrupt it using CTRL+C,
one thread is not killed - the main thread doing all graphics.
(Resulting in a badly messed up terminal, anyway.) I can kill
the program with killall -9 Rain though, and the raindrops stop.

I'm certainly no expert, but it would seem this problem is related to
the Linux posix thread implementation. Ncurses overwrites the SIGINT
signal - but only if handler is SIG_DFL. This is however true for
the thread which Ncurses is initialized in (main-method thread).

Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
it installed in the main thread? If not, how is GC cleanup/finalization
done?

Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Jeff Sturm]

Oskar Liljeblad wrote:
> 
> On Sunday, March 26, 2000 at 11:30, Jeff Sturm wrote:
> 
> > Actually no GC cleanup is needed (the runFinalizersOnExit method is
> > deprecated; I don't recall whether libgcj even implements it).  SIGINT
> > handling is necessary on Linux to ensure that all threads terminate, I
> > believe.  With other thread packages it may not be needed at all.
> 
> How do you deal with objects that override the finalize method,
> needing special finalization?

You don't.  The runtime is not obligated to finalize any object, and
generally does not perform finalization at exit.

Don't confuse finalization with C++ destructors.

-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Bryce McKinlay]

Oskar Liljeblad wrote:

> Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
> it installed in the main thread? If not, how is GC cleanup/finalization
> done?

What version of libgcj are you running? 2.95.1 does install a handler for
SIGINT which can cause problems like you describe. It should be fixed on
the current cvs version (if you are using libgcj from cvs, can you provide
a test case that demonstrates the problem?)

regards

  [ bryce ]

Re: threads+CNI+SIGINT

[Tom Tromey]

>> Actually no GC cleanup is needed (the runFinalizersOnExit method is
>> deprecated; I don't recall whether libgcj even implements it).  SIGINT
>> handling is necessary on Linux to ensure that all threads terminate, I
>> believe.  With other thread packages it may not be needed at all.

Oskar> How do you deal with objects that override the finalize method,
Oskar> needing special finalization?

Finalization works.
However, relying on it at shutdown time is probably a mistake.

Tom

Re: threads+CNI+SIGINT

[Bryce McKinlay]

Tom Tromey wrote:

> Jeff> In a native CNI method, what signal handlers (if any) can I
> Jeff> safely install?  Some signals are reserved by boehm-gc and
> Jeff> linuxthreads.  Is this documented?  (I know, I'm too
> Jeff> lazy/time-crunched to go look for myself.)
>
> This area isn't documented.
> You could probably handle any signal that isn't handled by the GC,
> LinuxThreads, or by the runtime (the runtime currently handles SIGSEGV,
> SIGFPE, and SIGPIPE).

Its best to NOT handle SIGINT and friends in a multithreaded application.
Linuxthreads knows how to clean up properly on these signals and adding
your own handler messes it up.

Implementing Runtime.addShutdownHook() should be the way to go for
terminal cleanups, etc. Do pthreads cleanup handlers get run on a SIGINT?

  [ bryce ]

Re: threads+CNI+SIGINT

[Jeff Sturm]

Tom Tromey wrote:
> Jeff> SIGINT handling is necessary on Linux to ensure that all threads
> Jeff> terminate, I believe.
> 
> What is it that we'd need to do?

I haven't tested/researched the issue yet... but I've had trouble with
other linuxthreads programs before, in which sending a signal to one PID
(thread) kills that thread, leaving the process running.  (At least the
IBM JDK behaves that way.)

That's not particularly nice behavior IMHO... the runtime should either
ignore the signal, or act on all threads (i.e. by shutting down).

A SIGINT from the keyboard (^C) will be automatically sent to all
processes which share the same controlling tty, which in that case will
probably do the right thing.

-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Cedric Berger]

Oskar Liljeblad wrote:

> How do you deal with objects that override the finalize method,
> needing special finalization?

Finalization must only be used for releasing resources like memory,
syncronization objects, ... which  means that its main use is for
native methods.

One exit, the OS will take care of freeing theses resources anyway,
with or without running finalization.

Override the finalize method for, say, closing a socket or a file is not
a good programming practice.

Cedric

Re: threads+CNI+SIGINT

[Oskar Liljeblad]

On Sunday, March 26, 2000 at 11:30, Jeff Sturm wrote:

> Actually no GC cleanup is needed (the runFinalizersOnExit method is
> deprecated; I don't recall whether libgcj even implements it).  SIGINT
> handling is necessary on Linux to ensure that all threads terminate, I
> believe.  With other thread packages it may not be needed at all.

How do you deal with objects that override the finalize method,
needing special finalization?

Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Jeff Sturm]

Oskar Liljeblad wrote:
> Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
> it installed in the main thread? If not, how is GC cleanup/finalization
> done?

Actually no GC cleanup is needed (the runFinalizersOnExit method is
deprecated; I don't recall whether libgcj even implements it).  SIGINT
handling is necessary on Linux to ensure that all threads terminate, I
believe.  With other thread packages it may not be needed at all.

--
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Oskar Liljeblad]

On Monday, March 27, 2000 at 08:05, Cedric Berger wrote:
>
> > How do you deal with objects that override the finalize method,
> > needing special finalization?
>
> Finalization must only be used for releasing resources like memory,
> syncronization objects, ... which  means that its main use is for
> native methods.

There is at least one situation in unix where it is (almost) absolutely
necessary: When you need to restore a terminal's state.

If I initialize ncurses natively in some object, I need to either
have the user manually restore the terminal, or do it during
finalization. I prefer the latter because it is easy to write buggy
code that never cleans up. (But it is also easy to write code that
always cleans up - except if the program wa killed by SIGINT/SIGTERM.)

Maybe there is some other solution to this problem that I'm missing...

Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Jeff Sturm]

Cedric Berger wrote:
> Finalization must only be used for releasing resources like memory,
> syncronization objects, ... which  means that its main use is for
> native methods.

No.  It is better to release all resources explicitly.  The
java.net.Socket class (for example) does have a close() method.  Your
code should always try to invoke close() before releasing the object. 
Finalization will probably eventually close it anyway, but it is poor
coding practice to rely on finalization that way.


-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Jeff Sturm]

Oskar Liljeblad wrote:
> If I initialize ncurses natively in some object, I need to either
> have the user manually restore the terminal, or do it during
> finalization. I prefer the latter because it is easy to write buggy
> code that never cleans up. (But it is also easy to write code that
> always cleans up - except if the program wa killed by SIGINT/SIGTERM.)

Don't use finalization for this.  Handling SIGINT is a problem that Java
doesn't solve, unfortunately... I've seen enhancement requests for
portable signal handling on JDC but I don't recall if they ever made it
into the core API (maybe in 1.3, I haven't looked).

In a native CNI method, what signal handlers (if any) can I safely
install?  Some signals are reserved by boehm-gc and linuxthreads.  Is
this documented?  (I know, I'm too lazy/time-crunched to go look for
myself.)

-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Tom Tromey]

>> Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
>> it installed in the main thread? If not, how is GC cleanup/finalization
>> done?

Jeff> Actually no GC cleanup is needed (the runFinalizersOnExit method
Jeff> is deprecated; I don't recall whether libgcj even implements
Jeff> it).

We do.

Jeff> SIGINT handling is necessary on Linux to ensure that all threads
Jeff> terminate, I believe.

What is it that we'd need to do?

Tom

Re: threads+CNI+SIGINT

[Tom Tromey]

>>>>> "Oskar" == Oskar Liljeblad <osk@hem.passagen.se> writes:

Oskar> There is at least one situation in unix where it is (almost)
Oskar> absolutely necessary: When you need to restore a terminal's
Oskar> state.

My recommendation is: don't use finalization to do this.

Tom

Re: threads+CNI+SIGINT

[Geoff Bull]

Jeff Sturm wrote:
> Don't confuse finalization with C++ destructors.

Yeah, the latter are useful.

Re: threads+CNI+SIGINT

[Cedric Berger]

I looks like that you'll have to wait for JDK1.3 that implements the
mechanism you want in Runtime.addShutdownHook.

see at:
http://java.sun.com/products/jdk/1.3/docs/api/java/lang/Runtime.html#addShutdownHook (java.lang.Thread)

Cedric




Oskar Liljeblad wrote:

> On Monday, March 27, 2000 at 08:05, Cedric Berger wrote:
> >
> > > How do you deal with objects that override the finalize method,
> > > needing special finalization?
> >
> > Finalization must only be used for releasing resources like memory,
> > syncronization objects, ... which  means that its main use is for
> > native methods.
>
> There is at least one situation in unix where it is (almost) absolutely
> necessary: When you need to restore a terminal's state.
>
> If I initialize ncurses natively in some object, I need to either
> have the user manually restore the terminal, or do it during
> finalization. I prefer the latter because it is easy to write buggy
> code that never cleans up. (But it is also easy to write code that
> always cleans up - except if the program wa killed by SIGINT/SIGTERM.)
>
> Maybe there is some other solution to this problem that I'm missing...
>
> Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Bryce McKinlay]

Tom Tromey wrote:

> Jeff> In a native CNI method, what signal handlers (if any) can I
> Jeff> safely install?  Some signals are reserved by boehm-gc and
> Jeff> linuxthreads.  Is this documented?  (I know, I'm too
> Jeff> lazy/time-crunched to go look for myself.)
>
> This area isn't documented.
> You could probably handle any signal that isn't handled by the GC,
> LinuxThreads, or by the runtime (the runtime currently handles SIGSEGV,
> SIGFPE, and SIGPIPE).

Its best to NOT handle SIGINT and friends in a multithreaded application.
Linuxthreads knows how to clean up properly on these signals and adding
your own handler messes it up.

Implementing Runtime.addShutdownHook() should be the way to go for
terminal cleanups, etc. Do pthreads cleanup handlers get run on a SIGINT?

  [ bryce ]

Re: threads+CNI+SIGINT

[Geoff Bull]

Jeff Sturm wrote:
> Don't confuse finalization with C++ destructors.

Yeah, the latter are useful.

Re: threads+CNI+SIGINT

[Jeff Sturm]

Tom Tromey wrote:
> Jeff> SIGINT handling is necessary on Linux to ensure that all threads
> Jeff> terminate, I believe.
> 
> What is it that we'd need to do?

I haven't tested/researched the issue yet... but I've had trouble with
other linuxthreads programs before, in which sending a signal to one PID
(thread) kills that thread, leaving the process running.  (At least the
IBM JDK behaves that way.)

That's not particularly nice behavior IMHO... the runtime should either
ignore the signal, or act on all threads (i.e. by shutting down).

A SIGINT from the keyboard (^C) will be automatically sent to all
processes which share the same controlling tty, which in that case will
probably do the right thing.

-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Tom Tromey]

Jeff> In a native CNI method, what signal handlers (if any) can I
Jeff> safely install?  Some signals are reserved by boehm-gc and
Jeff> linuxthreads.  Is this documented?  (I know, I'm too
Jeff> lazy/time-crunched to go look for myself.)

This area isn't documented.
You could probably handle any signal that isn't handled by the GC,
LinuxThreads, or by the runtime (the runtime currently handles SIGSEGV,
SIGFPE, and SIGPIPE).

Tom

Re: threads+CNI+SIGINT

[Jeff Sturm]

Oskar Liljeblad wrote:
> If I initialize ncurses natively in some object, I need to either
> have the user manually restore the terminal, or do it during
> finalization. I prefer the latter because it is easy to write buggy
> code that never cleans up. (But it is also easy to write code that
> always cleans up - except if the program wa killed by SIGINT/SIGTERM.)

Don't use finalization for this.  Handling SIGINT is a problem that Java
doesn't solve, unfortunately... I've seen enhancement requests for
portable signal handling on JDC but I don't recall if they ever made it
into the core API (maybe in 1.3, I haven't looked).

In a native CNI method, what signal handlers (if any) can I safely
install?  Some signals are reserved by boehm-gc and linuxthreads.  Is
this documented?  (I know, I'm too lazy/time-crunched to go look for
myself.)

-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Jeff Sturm]

Cedric Berger wrote:
> Finalization must only be used for releasing resources like memory,
> syncronization objects, ... which  means that its main use is for
> native methods.

No.  It is better to release all resources explicitly.  The
java.net.Socket class (for example) does have a close() method.  Your
code should always try to invoke close() before releasing the object. 
Finalization will probably eventually close it anyway, but it is poor
coding practice to rely on finalization that way.


-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Jeff Sturm]

Oskar Liljeblad wrote:
> 
> On Sunday, March 26, 2000 at 11:30, Jeff Sturm wrote:
> 
> > Actually no GC cleanup is needed (the runFinalizersOnExit method is
> > deprecated; I don't recall whether libgcj even implements it).  SIGINT
> > handling is necessary on Linux to ensure that all threads terminate, I
> > believe.  With other thread packages it may not be needed at all.
> 
> How do you deal with objects that override the finalize method,
> needing special finalization?

You don't.  The runtime is not obligated to finalize any object, and
generally does not perform finalization at exit.

Don't confuse finalization with C++ destructors.

-- 
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Tom Tromey]

>> Actually no GC cleanup is needed (the runFinalizersOnExit method is
>> deprecated; I don't recall whether libgcj even implements it).  SIGINT
>> handling is necessary on Linux to ensure that all threads terminate, I
>> believe.  With other thread packages it may not be needed at all.

Oskar> How do you deal with objects that override the finalize method,
Oskar> needing special finalization?

Finalization works.
However, relying on it at shutdown time is probably a mistake.

Tom

Re: threads+CNI+SIGINT

[Tom Tromey]

>>>>> "Oskar" == Oskar Liljeblad <osk@hem.passagen.se> writes:

Oskar> There is at least one situation in unix where it is (almost)
Oskar> absolutely necessary: When you need to restore a terminal's
Oskar> state.

My recommendation is: don't use finalization to do this.

Tom

Re: threads+CNI+SIGINT

[Tom Tromey]

>> Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
>> it installed in the main thread? If not, how is GC cleanup/finalization
>> done?

Jeff> Actually no GC cleanup is needed (the runFinalizersOnExit method
Jeff> is deprecated; I don't recall whether libgcj even implements
Jeff> it).

We do.

Jeff> SIGINT handling is necessary on Linux to ensure that all threads
Jeff> terminate, I believe.

What is it that we'd need to do?

Tom

Re: threads+CNI+SIGINT

[Cedric Berger]

I looks like that you'll have to wait for JDK1.3 that implements the
mechanism you want in Runtime.addShutdownHook.

see at:
http://java.sun.com/products/jdk/1.3/docs/api/java/lang/Runtime.html#addShutdownHook (java.lang.Thread)

Cedric




Oskar Liljeblad wrote:

> On Monday, March 27, 2000 at 08:05, Cedric Berger wrote:
> >
> > > How do you deal with objects that override the finalize method,
> > > needing special finalization?
> >
> > Finalization must only be used for releasing resources like memory,
> > syncronization objects, ... which  means that its main use is for
> > native methods.
>
> There is at least one situation in unix where it is (almost) absolutely
> necessary: When you need to restore a terminal's state.
>
> If I initialize ncurses natively in some object, I need to either
> have the user manually restore the terminal, or do it during
> finalization. I prefer the latter because it is easy to write buggy
> code that never cleans up. (But it is also easy to write code that
> always cleans up - except if the program wa killed by SIGINT/SIGTERM.)
>
> Maybe there is some other solution to this problem that I'm missing...
>
> Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Oskar Liljeblad]

On Monday, March 27, 2000 at 08:05, Cedric Berger wrote:
>
> > How do you deal with objects that override the finalize method,
> > needing special finalization?
>
> Finalization must only be used for releasing resources like memory,
> syncronization objects, ... which  means that its main use is for
> native methods.

There is at least one situation in unix where it is (almost) absolutely
necessary: When you need to restore a terminal's state.

If I initialize ncurses natively in some object, I need to either
have the user manually restore the terminal, or do it during
finalization. I prefer the latter because it is easy to write buggy
code that never cleans up. (But it is also easy to write code that
always cleans up - except if the program wa killed by SIGINT/SIGTERM.)

Maybe there is some other solution to this problem that I'm missing...

Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Cedric Berger]

Oskar Liljeblad wrote:

> How do you deal with objects that override the finalize method,
> needing special finalization?

Finalization must only be used for releasing resources like memory,
syncronization objects, ... which  means that its main use is for
native methods.

One exit, the OS will take care of freeing theses resources anyway,
with or without running finalization.

Override the finalize method for, say, closing a socket or a file is not
a good programming practice.

Cedric

Re: threads+CNI+SIGINT

[Oskar Liljeblad]

On Sunday, March 26, 2000 at 11:30, Jeff Sturm wrote:

> Actually no GC cleanup is needed (the runFinalizersOnExit method is
> deprecated; I don't recall whether libgcj even implements it).  SIGINT
> handling is necessary on Linux to ensure that all threads terminate, I
> believe.  With other thread packages it may not be needed at all.

How do you deal with objects that override the finalize method,
needing special finalization?

Oskar Liljeblad (osk@hem.passagen.se)

Re: threads+CNI+SIGINT

[Jeff Sturm]

Oskar Liljeblad wrote:
> Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
> it installed in the main thread? If not, how is GC cleanup/finalization
> done?

Actually no GC cleanup is needed (the runFinalizersOnExit method is
deprecated; I don't recall whether libgcj even implements it).  SIGINT
handling is necessary on Linux to ensure that all threads terminate, I
believe.  With other thread packages it may not be needed at all.

--
Jeff Sturm
jsturm@sigma6.com

Re: threads+CNI+SIGINT

[Bryce McKinlay]

Oskar Liljeblad wrote:

> Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
> it installed in the main thread? If not, how is GC cleanup/finalization
> done?

What version of libgcj are you running? 2.95.1 does install a handler for
SIGINT which can cause problems like you describe. It should be fixed on
the current cvs version (if you are using libgcj from cvs, can you provide
a test case that demonstrates the problem?)

regards

  [ bryce ]

threads+CNI+SIGINT

[Oskar Liljeblad]

I'm playing with ncurses in Java through CNI. There's a demo program,
called Rain, that I translated. It displays ASCII-art raindrops that
later disappears - like a screen saver.

When I compile and run this java program, and interrupt it using CTRL+C,
one thread is not killed - the main thread doing all graphics.
(Resulting in a badly messed up terminal, anyway.) I can kill
the program with killall -9 Rain though, and the raindrops stop.

I'm certainly no expert, but it would seem this problem is related to
the Linux posix thread implementation. Ncurses overwrites the SIGINT
signal - but only if handler is SIG_DFL. This is however true for
the thread which Ncurses is initialized in (main-method thread).

Don't GCJ-compiled programs have some SIGINT handler? If so, why isn't
it installed in the main thread? If not, how is GC cleanup/finalization
done?

Oskar Liljeblad (osk@hem.passagen.se)