[concurrency-interest] Upcoming jdk9 j.u.c JEP

Doug Lea dl at cs.oswego.edu
Fri Jul 24 14:52:49 EDT 2015

On 07/23/2015 02:55 PM, Dávid Karnok wrote:

> I've read through the code and javadoc and I have the following comments:

Thanks! I addressed all except the ones discussed below:

> Line 70: the code schedules the exception with executor.execute(() ->
> subscriber.onError(ex)); but the subscriber can't cancel this action. For
> example, a subscriber calling request(-1) and then cancel() will inevitably
> receive the exception. I understand the RS spec allows for such late-coming
> events, but since this is an example, it should convey the right practices: one
> should always get the future of a scheduled action.

This is illustrated with the simple OneShot version to minimize sample code
size of a minimal fully compliant implementation at the expense of
glossing over nuances. Unless you see a trivial change that would convey
this, just adding something to more nicely address { request(-1); cancel()} 
would probably impair understandability more than it would help.

> Line 98: the text reads "Subscriber maintains multiple Subscriptions" which I
> don't see how would look like and I think the RS spec at least implies this
> shouldn't happen.

Right. The next sentence tells people what to do instead:

  * Subscription} are strictly ordered, there is no need for these
  * methods to use locks or volatiles unless a Subscriber maintains
  * multiple Subscriptions (in which case it is better to instead
  * define multiple Subscribers, each with its own Subscription).

I suppose it could be strengthened by replacing "better" with
"less insane" :-)

> Line 114: the count variable is set after the request is issued so a synchronous
> onNext call will request bufferSize - bufferSize / 2 immediately, having a total
> of ~1.5 * bufferSize outstanding requests.

Not immediately: count is also initially set to: bufferSize - bufferSize / 2.

(It is nice to illustrate early on that people can use
techniques other than item-by-item request(1). This is the
least code-intensive one I could think of.)

> Line 416: the text reads "Preliminary release note: Currently, this method
> collects all items before executing the stream computation." Correct me if I'm
> wrong, but since Stream is pull based, the stream() method would need to inject
> concurrency into the flow:

Yes, in general, it should. The implementation is currently a stand-in.

> Line 222: From experience with RxJava, holding a lock while emitting events
> should be avoided, especially when blocking actions are nearby.

Right. Almost everything is lock-free. However, there is nothing
preventing two different threads generating items into the
same SubmissionPublisher, so this lock keeps the class fully
thread-safe in this case. It does come at the expense of
possibly blocking during onSubscribe, but still seems to be
the best tradeoff.

> Line 230: In RxJava, if the Subject is terminated with an exception, late
> Subscribers will receive the exception but here, they just get completed. Maybe
> it is worth considering this exception-replaying behavior.

Thanks. I'm going to sit on this for the moment. One alternative is
to add method isClosedExceptionally so that only those new Subscribers
that care how it was closed need to arrange special handling.

> Line 623: getSubscribers() why would anyone be interested in the actual
> subscribers? Calling methods on them shouldn't be allowed anyway and I don't see
> any other reason to expose them.

As noted in the javadoc, it is just for monitoring and management.
We have a lot of methods along these line in j.u.c, that aren't used much,
but people appreciate them when they need them.


More information about the Concurrency-interest mailing list