misc catchup (original) (raw)

Doug Lea dl at cs.oswego.edu
Thu Nov 1 04:53:33 PDT 2012

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

More information about the lambda-libs-spec-observers mailing list