public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: threads+CNI+SIGINT
@ 2000-03-27  8:27 Oskar Liljeblad
  2000-03-27  8:40 ` threads+CNI+SIGINT Cedric Berger
                   ` (3 more replies)
  0 siblings, 4 replies; 36+ messages in thread
From: Oskar Liljeblad @ 2000-03-27  8:27 UTC (permalink / raw)
  To: cedric; +Cc: java-discuss

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:27 threads+CNI+SIGINT Oskar Liljeblad
@ 2000-03-27  8:40 ` Cedric Berger
  2000-04-01  0:00   ` threads+CNI+SIGINT Cedric Berger
  2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 36+ messages in thread
From: Cedric Berger @ 2000-03-27  8:40 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: java-discuss

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:27 threads+CNI+SIGINT Oskar Liljeblad
  2000-03-27  8:40 ` threads+CNI+SIGINT Cedric Berger
@ 2000-03-27  8:47 ` Tom Tromey
  2000-04-01  0:00   ` threads+CNI+SIGINT Tom Tromey
  2000-03-27  9:03 ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
  3 siblings, 1 reply; 36+ messages in thread
From: Tom Tromey @ 2000-03-27  8:47 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: cedric, java-discuss

>>>>> "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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:27 threads+CNI+SIGINT Oskar Liljeblad
  2000-03-27  8:40 ` threads+CNI+SIGINT Cedric Berger
  2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
@ 2000-03-27  9:03 ` Jeff Sturm
  2000-03-27  9:12   ` threads+CNI+SIGINT Tom Tromey
  2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
  3 siblings, 2 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-03-27  9:03 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: cedric, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  9:03 ` threads+CNI+SIGINT Jeff Sturm
@ 2000-03-27  9:12   ` Tom Tromey
  2000-03-27 16:36     ` threads+CNI+SIGINT Bryce McKinlay
  2000-04-01  0:00     ` threads+CNI+SIGINT Tom Tromey
  2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
  1 sibling, 2 replies; 36+ messages in thread
From: Tom Tromey @ 2000-03-27  9:12 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Oskar Liljeblad, cedric, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  9:12   ` threads+CNI+SIGINT Tom Tromey
@ 2000-03-27 16:36     ` Bryce McKinlay
  2000-04-01  0:00       ` threads+CNI+SIGINT Bryce McKinlay
  2000-04-01  0:00     ` threads+CNI+SIGINT Tom Tromey
  1 sibling, 1 reply; 36+ messages in thread
From: Bryce McKinlay @ 2000-03-27 16:36 UTC (permalink / raw)
  To: Tom Tromey, java-discuss

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 ]



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  9:12   ` threads+CNI+SIGINT Tom Tromey
  2000-03-27 16:36     ` threads+CNI+SIGINT Bryce McKinlay
@ 2000-04-01  0:00     ` Tom Tromey
  1 sibling, 0 replies; 36+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Oskar Liljeblad, cedric, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27 16:36     ` threads+CNI+SIGINT Bryce McKinlay
@ 2000-04-01  0:00       ` Bryce McKinlay
  0 siblings, 0 replies; 36+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey, java-discuss

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 ]



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:27 threads+CNI+SIGINT Oskar Liljeblad
                   ` (2 preceding siblings ...)
  2000-03-27  9:03 ` threads+CNI+SIGINT Jeff Sturm
@ 2000-04-01  0:00 ` Oskar Liljeblad
  3 siblings, 0 replies; 36+ messages in thread
From: Oskar Liljeblad @ 2000-04-01  0:00 UTC (permalink / raw)
  To: cedric; +Cc: java-discuss

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  9:03 ` threads+CNI+SIGINT Jeff Sturm
  2000-03-27  9:12   ` threads+CNI+SIGINT Tom Tromey
@ 2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 0 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: cedric, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
@ 2000-04-01  0:00   ` Tom Tromey
  0 siblings, 0 replies; 36+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: cedric, java-discuss

>>>>> "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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:40 ` threads+CNI+SIGINT Cedric Berger
@ 2000-04-01  0:00   ` Cedric Berger
  0 siblings, 0 replies; 36+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: java-discuss

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* threads+CNI+SIGINT
  2000-03-26  0:41 threads+CNI+SIGINT Oskar Liljeblad
  2000-03-26  2:19 ` threads+CNI+SIGINT Bryce McKinlay
  2000-03-26  8:04 ` threads+CNI+SIGINT Jeff Sturm
@ 2000-04-01  0:00 ` Oskar Liljeblad
  2 siblings, 0 replies; 36+ messages in thread
From: Oskar Liljeblad @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss; +Cc: osk

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:48 ` threads+CNI+SIGINT Jeff Sturm
  2000-03-27 15:57   ` threads+CNI+SIGINT Geoff Bull
@ 2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 0 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-26  2:19 ` threads+CNI+SIGINT Bryce McKinlay
@ 2000-04-01  0:00   ` Bryce McKinlay
  0 siblings, 0 replies; 36+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: osk; +Cc: java-discuss

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 ]


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
@ 2000-04-01  0:00   ` Tom Tromey
  0 siblings, 0 replies; 36+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: jsturm, java-discuss

>> 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


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  9:17     ` threads+CNI+SIGINT Jeff Sturm
@ 2000-04-01  0:00       ` Jeff Sturm
  0 siblings, 0 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: osk, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:11 ` threads+CNI+SIGINT Cedric Berger
  2000-03-27  8:52   ` threads+CNI+SIGINT Jeff Sturm
@ 2000-04-01  0:00   ` Cedric Berger
  1 sibling, 0 replies; 36+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  7:56 threads+CNI+SIGINT Oskar Liljeblad
                   ` (2 preceding siblings ...)
  2000-03-27  8:48 ` threads+CNI+SIGINT Jeff Sturm
@ 2000-04-01  0:00 ` Oskar Liljeblad
  3 siblings, 0 replies; 36+ messages in thread
From: Oskar Liljeblad @ 2000-04-01  0:00 UTC (permalink / raw)
  To: jsturm; +Cc: java-discuss

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-26  8:04 ` threads+CNI+SIGINT Jeff Sturm
  2000-03-27  8:46   ` threads+CNI+SIGINT Tom Tromey
@ 2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 0 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: osk; +Cc: java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-26  2:57 ` threads+CNI+SIGINT Oskar Liljeblad
@ 2000-04-01  0:00   ` Oskar Liljeblad
  0 siblings, 0 replies; 36+ messages in thread
From: Oskar Liljeblad @ 2000-04-01  0:00 UTC (permalink / raw)
  To: bryce; +Cc: java-discuss

> > 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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:52   ` threads+CNI+SIGINT Jeff Sturm
@ 2000-04-01  0:00     ` Jeff Sturm
  0 siblings, 0 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: Oskar Liljeblad, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:46   ` threads+CNI+SIGINT Tom Tromey
  2000-03-27  9:17     ` threads+CNI+SIGINT Jeff Sturm
@ 2000-04-01  0:00     ` Tom Tromey
  1 sibling, 0 replies; 36+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: osk, java-discuss

>> 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


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27 15:57   ` threads+CNI+SIGINT Geoff Bull
@ 2000-04-01  0:00     ` Geoff Bull
  0 siblings, 0 replies; 36+ messages in thread
From: Geoff Bull @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

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

Yeah, the latter are useful.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:48 ` threads+CNI+SIGINT Jeff Sturm
@ 2000-03-27 15:57   ` Geoff Bull
  2000-04-01  0:00     ` threads+CNI+SIGINT Geoff Bull
  2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
  1 sibling, 1 reply; 36+ messages in thread
From: Geoff Bull @ 2000-03-27 15:57 UTC (permalink / raw)
  To: java-discuss

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

Yeah, the latter are useful.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:46   ` threads+CNI+SIGINT Tom Tromey
@ 2000-03-27  9:17     ` Jeff Sturm
  2000-04-01  0:00       ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00     ` threads+CNI+SIGINT Tom Tromey
  1 sibling, 1 reply; 36+ messages in thread
From: Jeff Sturm @ 2000-03-27  9:17 UTC (permalink / raw)
  To: Tom Tromey; +Cc: osk, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  8:11 ` threads+CNI+SIGINT Cedric Berger
@ 2000-03-27  8:52   ` Jeff Sturm
  2000-04-01  0:00     ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00   ` threads+CNI+SIGINT Cedric Berger
  1 sibling, 1 reply; 36+ messages in thread
From: Jeff Sturm @ 2000-03-27  8:52 UTC (permalink / raw)
  To: Cedric Berger; +Cc: Oskar Liljeblad, java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  7:56 threads+CNI+SIGINT Oskar Liljeblad
  2000-03-27  8:11 ` threads+CNI+SIGINT Cedric Berger
  2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
@ 2000-03-27  8:48 ` Jeff Sturm
  2000-03-27 15:57   ` threads+CNI+SIGINT Geoff Bull
  2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
  3 siblings, 2 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-03-27  8:48 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  7:56 threads+CNI+SIGINT Oskar Liljeblad
  2000-03-27  8:11 ` threads+CNI+SIGINT Cedric Berger
@ 2000-03-27  8:47 ` Tom Tromey
  2000-04-01  0:00   ` threads+CNI+SIGINT Tom Tromey
  2000-03-27  8:48 ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
  3 siblings, 1 reply; 36+ messages in thread
From: Tom Tromey @ 2000-03-27  8:47 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: jsturm, java-discuss

>> 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


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-26  8:04 ` threads+CNI+SIGINT Jeff Sturm
@ 2000-03-27  8:46   ` Tom Tromey
  2000-03-27  9:17     ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00     ` threads+CNI+SIGINT Tom Tromey
  2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
  1 sibling, 2 replies; 36+ messages in thread
From: Tom Tromey @ 2000-03-27  8:46 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: osk, java-discuss

>> 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


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-27  7:56 threads+CNI+SIGINT Oskar Liljeblad
@ 2000-03-27  8:11 ` Cedric Berger
  2000-03-27  8:52   ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00   ` threads+CNI+SIGINT Cedric Berger
  2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 36+ messages in thread
From: Cedric Berger @ 2000-03-27  8:11 UTC (permalink / raw)
  To: Oskar Liljeblad; +Cc: java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
@ 2000-03-27  7:56 Oskar Liljeblad
  2000-03-27  8:11 ` threads+CNI+SIGINT Cedric Berger
                   ` (3 more replies)
  0 siblings, 4 replies; 36+ messages in thread
From: Oskar Liljeblad @ 2000-03-27  7:56 UTC (permalink / raw)
  To: jsturm; +Cc: java-discuss

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-26  0:41 threads+CNI+SIGINT Oskar Liljeblad
  2000-03-26  2:19 ` threads+CNI+SIGINT Bryce McKinlay
@ 2000-03-26  8:04 ` Jeff Sturm
  2000-03-27  8:46   ` threads+CNI+SIGINT Tom Tromey
  2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
  2 siblings, 2 replies; 36+ messages in thread
From: Jeff Sturm @ 2000-03-26  8:04 UTC (permalink / raw)
  To: osk; +Cc: java-discuss

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
       [not found] <20000326115435.A4986@oskar>
@ 2000-03-26  2:57 ` Oskar Liljeblad
  2000-04-01  0:00   ` threads+CNI+SIGINT Oskar Liljeblad
  0 siblings, 1 reply; 36+ messages in thread
From: Oskar Liljeblad @ 2000-03-26  2:57 UTC (permalink / raw)
  To: bryce; +Cc: java-discuss

> > 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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: threads+CNI+SIGINT
  2000-03-26  0:41 threads+CNI+SIGINT Oskar Liljeblad
@ 2000-03-26  2:19 ` Bryce McKinlay
  2000-04-01  0:00   ` threads+CNI+SIGINT Bryce McKinlay
  2000-03-26  8:04 ` threads+CNI+SIGINT Jeff Sturm
  2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
  2 siblings, 1 reply; 36+ messages in thread
From: Bryce McKinlay @ 2000-03-26  2:19 UTC (permalink / raw)
  To: osk; +Cc: java-discuss

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 ]


^ permalink raw reply	[flat|nested] 36+ messages in thread

* threads+CNI+SIGINT
@ 2000-03-26  0:41 Oskar Liljeblad
  2000-03-26  2:19 ` threads+CNI+SIGINT Bryce McKinlay
                   ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Oskar Liljeblad @ 2000-03-26  0:41 UTC (permalink / raw)
  To: java-discuss; +Cc: osk

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)

^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-27  8:27 threads+CNI+SIGINT Oskar Liljeblad
2000-03-27  8:40 ` threads+CNI+SIGINT Cedric Berger
2000-04-01  0:00   ` threads+CNI+SIGINT Cedric Berger
2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
2000-04-01  0:00   ` threads+CNI+SIGINT Tom Tromey
2000-03-27  9:03 ` threads+CNI+SIGINT Jeff Sturm
2000-03-27  9:12   ` threads+CNI+SIGINT Tom Tromey
2000-03-27 16:36     ` threads+CNI+SIGINT Bryce McKinlay
2000-04-01  0:00       ` threads+CNI+SIGINT Bryce McKinlay
2000-04-01  0:00     ` threads+CNI+SIGINT Tom Tromey
2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
  -- strict thread matches above, loose matches on Subject: below --
2000-03-27  7:56 threads+CNI+SIGINT Oskar Liljeblad
2000-03-27  8:11 ` threads+CNI+SIGINT Cedric Berger
2000-03-27  8:52   ` threads+CNI+SIGINT Jeff Sturm
2000-04-01  0:00     ` threads+CNI+SIGINT Jeff Sturm
2000-04-01  0:00   ` threads+CNI+SIGINT Cedric Berger
2000-03-27  8:47 ` threads+CNI+SIGINT Tom Tromey
2000-04-01  0:00   ` threads+CNI+SIGINT Tom Tromey
2000-03-27  8:48 ` threads+CNI+SIGINT Jeff Sturm
2000-03-27 15:57   ` threads+CNI+SIGINT Geoff Bull
2000-04-01  0:00     ` threads+CNI+SIGINT Geoff Bull
2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad
     [not found] <20000326115435.A4986@oskar>
2000-03-26  2:57 ` threads+CNI+SIGINT Oskar Liljeblad
2000-04-01  0:00   ` threads+CNI+SIGINT Oskar Liljeblad
2000-03-26  0:41 threads+CNI+SIGINT Oskar Liljeblad
2000-03-26  2:19 ` threads+CNI+SIGINT Bryce McKinlay
2000-04-01  0:00   ` threads+CNI+SIGINT Bryce McKinlay
2000-03-26  8:04 ` threads+CNI+SIGINT Jeff Sturm
2000-03-27  8:46   ` threads+CNI+SIGINT Tom Tromey
2000-03-27  9:17     ` threads+CNI+SIGINT Jeff Sturm
2000-04-01  0:00       ` threads+CNI+SIGINT Jeff Sturm
2000-04-01  0:00     ` threads+CNI+SIGINT Tom Tromey
2000-04-01  0:00   ` threads+CNI+SIGINT Jeff Sturm
2000-04-01  0:00 ` threads+CNI+SIGINT Oskar Liljeblad

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).