On 02/23/2016 04:30 PM, Vitaly Davidovich wrote:
Why not drop the (superfluous, IMO) "on" prefix while you're changing the
receiver?
Because then it reads as if the method itself is doing a spinWait.
"onSpinWait" is the only proposed name that no one has said they cannot
live with. So, live with it :-)
-Doug
On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene <g...@azul.com> wrote:
On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote:
2016/1/28 9:25 -0800, g...@azul.com:
This thread seems to have "hopped away" to the concurrency-interest
list in mid-Dec-2015. This posting is intended to capture a summary of
reasoning and some of the discussion there so that we have it in the
record in core-libs-dev. Mostly by including the contents of several
posts in the continuations of the original thread.
See thread continuations here:
http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14576
and here:
http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14580
Summary:
...
Thanks for the summary.
I still don't buy the argument that this method belongs in j.l.Runtime.
To say that this method should go there because it's an instruction to
the run-time system is pretty weak. I agree with Vitaly [1] that if
that's the threshold for adding methods to the Runtime class then lots
of other stuff belongs there as well, including much of what's now in
java.lang.Thread and java.util.concurrent and, arguably, anything else
related to interacting with the environment in which the application
runs (file and network I/O, process manipulation, etc.).
This thread-related method really belongs in either java.lang.Thread or
java.util.concurrent.LockSupport. j.l.Thread already has plenty of
expert-level static methods related to the current thread, one of which
(Thread::yield) is even a hint, just like this one. j.u.c.LockSupport
is even more obviously intended for expert users and hence may be the
best choice, but I could live with either one.
Ok. In the interest of moving forward, lets settle on:
Thread.onSpinWait()
Same logic for the name, different receiver for the event. I can certainly
live with it, and Doug seems ok with it as well.
— Gil.
