On 29/04/2020 08:10, Peter Levart wrote:
Right, as you saw in a private Email, I did exactly that in a revised
version (posted below). The spurious ISE may happen but only when
close is called prematurely relative to all child scope close(s) that
were or are still active. So we could say the other way: if close was
not called prematurely, the ISE on acquire would not be spurious - so
ordering of close relative to later acquire was wrong anyway and the
exception is an "indication" of that wrong ordering
Unless we want to use close() to "probe" the scope whether it is still
active or not, I don't think this should present a problem.
One quick comment: unless I'm missing something, this is starting to
make a pretty strong assumption on how acquire()/close() are going to be
used. Yes, if acquire() is not exposed to developers (as in the current
API) and only hidden behind a spliterator, we might get away with this;
but should we at some point re-introduce some kind of explicit acquire
mechanism in the API, then such an assumption would not be a fine one to
make.
Maurizio
