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

Inconsistent variable binding in @async blocks #3713

Closed
amitmurthy opened this issue Jul 14, 2013 · 3 comments
Closed

Inconsistent variable binding in @async blocks #3713

amitmurthy opened this issue Jul 14, 2013 · 3 comments
Labels
needs tests Unit tests are required for this change

Comments

@amitmurthy
Copy link
Contributor

The same @sync blocks below, run twice results in different outputs

  • in the first run, variable t is bound to the value when it is printed
  • in the second run, variable t is bound to the value when the block is entered
 _/ |\__'_|_|_|\__'_|  |  Commit 563ba1c84 2013-07-14 04:02:55*
|__/                   |  x86_64-linux-gnu

julia> @sync begin
           t = false
           @async begin
               sleep(1.0)
               print("1: ", t, "\n")
           end

           t = true
       end
1: true
true

julia> @sync begin
           t = false
           @async begin
               sleep(1.0)
               print("1: ", t, "\n")
           end

           t = true
       end
1: false
true

julia>
@StefanKarpinski
Copy link
Sponsor Member

If you change this to a let block it's 1: false both times.

@amitmurthy
Copy link
Contributor Author

Yeah, but let blocks create new local bindings.

Came across this anomaly when I was trying to figure out https://groups.google.com/d/topic/julia-users/YDxPRQhygAA/discussion

@amitmurthy
Copy link
Contributor Author

Closed by #19594

@tkelman tkelman added the needs tests Unit tests are required for this change label Jan 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs tests Unit tests are required for this change
Projects
None yet
Development

No branches or pull requests

3 participants