Re: [cp-patches] Implementing Thread.sleep() via Thread.wait()

[Mark Wielaard]

Hi Archie,

On Sat, 2005-01-01 at 10:13 -0600, Archie Cobbs wrote:
> To everyone on the list: please come to agreement about whether
> Thread.sleep(0) should throw InterruptedException or just be
> equivalent to Thread.yield() (personally, I'm happy either way).
> Then I will make the changes as necessary.

Obviously I would have preferred the implementation of Thread.sleep()
being pushed into VMThread.sleep() combined your suggested Object.wait()
implementation. That would have kept documentation and mauve tests
consistent. I can live with your interpretation and implementation as
long as it is consistently used.  Since you have already committed the
code you are responsible to update the documentation and mauve tests to
reflect this (as I pointed out in my other email [*]). Since currently
the documentation, tests and implementation are out of sync that should
be fixed.

Thanks,

Mark

P.S. I will comment on the native library class loader changes later. I
like them in general, but I am really trying to test and package a new
developer snapshot release today and testing and integrating that patch
is a bit more work than I want to do today.

[*]

> We want to provide an implementation and documentation that is usable
> without reference to any interpretations of specific behavior of
> non-free proprietary implementation (bugs). And the documentation
> should be helpful not only to runtime implementers (which should look
> in VMThread) but also (more importantly imho) to developers using the
> public classes. So if you really want to push this implementation
> document clearly that the InterruptedException is never thrown if all
> arguments are zero even if the thread is in interrupted state, that
> the interrupted state will/will not (?) be cleared, and that the
> threading behavior is like Thread.yield() was called. You can mention
> that bug report you files against some other implementation in the
> implementation notes/comments if you want, but don't use it in the
> public description of the methods.
> [...]
> I rather not see this patch go in this way (I prefer a default
> implementation that does the right thing). But if you really feel
> passionately about this and update mauve and the documentation to
> reflect this interpretation I won't object.

signature.asc
Description: This is a digitally signed message part