Re: Thread/VMThread proposal

[Brian Jones]

Jeroen Frijters <address@hidden> writes:

> > - You may need more lifecycle management in VMThread. For example, a
> > thread that has stop() called on it before it is started is
> > "stillborn".
> 
> The docs do say that, but my tests suggest that Sun just ignores stop()
> when called on an unstarted thread. Should we implement what the docs
> say, or emulate the Sun implementation? In most cases (including this
> one), my preference is to do what Sun does.

You may wish to check that a "stillborn" thread has a null thread
group after stop() has been called.  I did confirm already that
threads that run and are stopped are seen to have a null thread group.

> > - VMThread.join() should be implemented using wait/notify not using a
> > polling loop with sleep. Your VMThread.run would then do the notifyAll
> > upon termination.
> 
> IMHO, this is too heavyweight for the default VMThread. I expect most
> VMs to supply their own version of VMThread which has a better
> implementation of join (based on some native join-like mechanism). I
> agree the default is lame, but I don't think putting time into improving
> it is worthwhile if no-one is going to use it. Of course, by this
> argument it should probably be taken out entirely and made native.

I think you can avoid polling/sleep.

-- 
Brian Jones <address@hidden>