do we need separate thread for FirstThread

Bryce McKinlay bryce@albatross.co.nz
Thu Feb 8 15:38:00 GMT 2001


Per Bothner wrote:

> * Avoid creating threads in single-threaded programs.

Well, we can't really do this, since a separate finalization thread (for
example) will be required in order to implement finalization correctly.
It may eventually be nice to have an asynchronous GC thread too, for
better performance in GUI apps.

>  I've tried using gdb on Kawa, and there
> are major problems.

Yep, gdb Java support has major problems, but threads in my experience
threads do work reasonably well in gdb these days. I found it sometimes
useful to delete or rename the /lib/libthread_db.so however, particularly
when debugging the libgcj threads layer itself.

> For example,
> it seems like the thread library (pthreads on Linux) causes lots
> of signals that are reported by Gdb.

This is strange. Linuxthreads since v2.1 has used realtime signals, and
gdb since ~5.0 has known to ignore them. Perhaps you are actually seeing
the GC's signals? In any case, you should read
http://gcc.gnu.org/java/gdb.html

> * The JNI invocation interface requires the ability to attach a
> JVM to an existing native thread.

Yes. It will also be good to have a CNI invocation interface.

> The last I think is the killer argument, but the other ones
> are also worth noting. So what are the arguments in favor of
> starting a separate native thread?

The reason why we have a separate main thread currently is because it is
simply easier and cleaner to do this way. We have to take into account
Java daemon threads, which have to keep running even if main() exits, and
provide a place to implement shutdown hooks (a 1.3 API).

That said, given that we need to solve these problems anyway for the
invocation interfaces, I have no objection to making the main C thread
the main Java thread. Its just that it is trickier than you might think
;-)

regards

  [ bryce ]




More information about the Java mailing list