misc catchup

[Doug Lea]

On 10/31/12 20:45, David Holmes wrote:

> Okay - so that raised a point I forgot to raise - this common pool is always
> created, not just on demand. I understand the expectation is that anyone loading
> FJP will in all likelihood be using the common pool. But my concern is that pool
> initialization is part of the class static initialization, so if anything goes
> wrong the class will be unusable. My main concern is potential
> SecurityExceptions from the getProperty calls. Am I being paranoid? :)
>

This deserves some attention. If the static-init occurs from
the context of an unprivileged thread, we probably still want to
create it in some default form. Further, if that thread tries
to use it, then invokes etc will still work, without creating any
workers (which we handle but needs some adjustment about
not throwing RejectedExecution in some cases.) Sound OK?

Backing up a little, the main precipitating factor in
doing all this is that on platforms with power management,
core fusion, and/or uncooperative OS schedules, it can sometimes
take millions of cycles for woken threads to actually do anything.
So the best thing is for the caller of invoke to do some
(or even all) of the work itself. The adaptive dynamics
for doing this are best done inside FJP, not by user
or lambda-lib code, but only possible if they are running
on a common pool. So that's what I'm working on.
I'm making slow steady progress, but there will surely be
a bunch of FJP/FJT changes in the short term.
Brian and Aleksey: For one, "helpComplete" will
be un-introduced (back to just "tryComplete") in next commit.
I have to catch and cope with propagation at join/invoke
time for submissions anyway, so there's no reason to
support a hinting form.

-Doug