Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to reset a blocking variable #718

Closed
wants to merge 1 commit into from
Closed

Allow to reset a blocking variable #718

wants to merge 1 commit into from

Conversation

guenhter
Copy link

Often it's needed to use the same BlockingVariable again but reset it. E.g. when the variable is used for Messaging and is contained in a consumer. Than it isn't always that easy to replace the existing variable with a new instance. So I added a simple reset method which resets the value and the CountDownLatch of the BlockingVariable.

This also was suggested in
#312

So it is now possible to do:

BlockingVariable<String> b = ...
// do something async with the var

when:
sender.send("val1")
then:
b.get() == "val1"

when:
b.reset()
sender.send("val2")
then:
b.get() == "val2"

when:
b.reset()
sender.error();
b.get()
then:
thrown(SpockTimeoutError)

(I know, this samples can be split up to own tests, but there are other circumstances where such cases are needed)

@leonard84
Copy link
Member

Hi @guenhter thanks for the PR, but this fundamentally changes the behavior of the BlockingVariable and breaks the promise of thread-safety, and it would behave differently than BlockingVariables. BlockingVariable is similar to gpars' DataflowVariable in that it

Represents a thread-safe single-assignment, multi-read variable

If we would support this, then it should probably be in a new class ReuseableBlockingVariable and then you'd need to take care regarding synchronization and memory barriers as well.

@guenhter
Copy link
Author

Hi @leonard84

appreciate your suggestion. Seems like a clean solution to add a new class in order not to violate the contract of BlockingVariable.
Would it be a problem for you, if the BlockingVariable will be extended about one new method
abort which wakes up all blocked threads and let them fail with a SpockTimeoutError?

@leonard84
Copy link
Member

What would be the usecase, the BlockingVariable already has a timeout built-in, and who would call abort?

@guenhter
Copy link
Author

@leonard84 I would like to reuse the BlockingVariable in my ReuseableBlockingVariable and when that one is reset, all current blocking get() methods should be woken up.

Even though I can think of use cases (I also already have) if someone wait within the get() and an exceptional path is entered where I wanted to wake up those blocked threads. I managed that by setting a very special value and than check if the get() returned with that value and then throw the exception myself.

@leonard84
Copy link
Member

leonard84 commented Apr 15, 2017

Hm, who is controlling your ReuseableBlockingVariable (reset)? Is it the spec, if so who is waiting in get?

The scenario which I see for ReuseableBlockingVariable is what you described above, so there is no one else waiting on get() and no one else calling reset(), other than the spec itself.

@guenhter
Copy link
Author

#721

@guenhter guenhter closed this Apr 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants