Re: ManagedBlocker.block() documentation

Maybe is should actually be put in code. Something like

public interface ManagedBlocker {

    // Note: Runnable is not a good choice, the method show allow to
throw an InterruptedException
    static ManagedBlocker blocker(Runnable blockingOperation) {
        return new ManagedBlocker() { // Probably better to have a
real class, not an anonymous one
            private volatile boolean done; // Is volatile needed?

            public boolean block() throws InterruptedException {
                if (!isReleasable()) {
                    blockingOperation.run();
                    done = true;
                }
                return isReleasable();
            }

            public boolean isReleasable() {
                return done;
            }
        };
    }
    boolean block() throws InterruptedException;
    boolean isReleasable();
}


On Wed, 30 Oct 2019 at 04:00, Viktor Klang via Concurrency-interest <
[email protected]> wrote:

> I typically do this:
>
> class MyBlocker implements ManagedBlocker {
>   boolean done;
>   boolean block() {
>     if (!isReleasable()) {
>       doMyOneOffBlockingOp();
>       done = true;
>     }
>     return isReleasable();
>   }
>   boolean isReleasable() { return done; }
> }
>
> In Scala I added a `blocking` construct which takes a thunk so the users
> can write:
>
> val result = blocking { doMyOneOffBlockingOp() }
>
> On Wed, Oct 30, 2019 at 7:26 AM Roman Leventov via Concurrency-interest <
> [email protected]> wrote:
>
>> Currently, ManagedBlocker's documentation doesn't clarify whether the
>> execution framework could call block() more than once or not. The
>> specification for the return value of block() method:
>>
>> > true if no additional blocking is necessary (i.e., if isReleasable
>> would return true)
>>
>> Implies that isReleasable result should change if block() returns true.
>>
>> It means that to code one-off blocking ops with ManagedBlocker, strictly
>> against the spec, one must make block() idempotent:
>>
>> class MyBlocker implements ManagedBlocker {
>>   boolean done = false;
>>   boolean block() {
>>     if (done) return true;
>>     doMyOneOffBlockingOp();
>>     done = true;
>>     return true;
>>   }
>>   boolean isReleasable() { return done; }
>> }
>>
>> Which is 1) boilerplate 2) non-trivial conclusion, implicit in the doc
>> (so few people would probably do this; e. g. there is an SO answer from a
>> very reputable folk that ditch this complexity and call it an "official
>> solution": https://stackoverflow.com/a/46073118/648955)
>>
>> So, perhaps, it would make sense to extend the documentation
>> of ManagedBlocker with reservations about one-off blocking operations, e.
>> g. like this:
>>
>> @return true if no additional blocking is necessary (i.e., if
>> isReleasable would return true, or if block() is a one-off operation)
>> _______________________________________________
>> Concurrency-interest mailing list
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
> --
> Cheers,
> √
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest