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

Should App.run_after use GCD? #180

Open
taybenlor opened this issue Dec 24, 2012 · 10 comments
Open

Should App.run_after use GCD? #180

taybenlor opened this issue Dec 24, 2012 · 10 comments

Comments

@taybenlor
Copy link

I'm currently spicing up one of my RubyMotion apps with BubbleWrap. A little bit of code I have works fine with GCD but crashes using App.run_after. My knowledge of the Objective C threading model and Timers vs GCD is limited, so I'm not sure whether this would break a bunch of existing code.

Anyway, my example:

loc = @mapView.region.center

Dispatch::Queue.main.after 0.4 do 
  new_loc = @mapView.region.center
  if loc == new_loc
    self.updateLocation
  end
end

The change to BubbleWrap would be super quick, though I haven't made the change and tested it. Just wanted to check it was a sane thing to do.

@siuying
Copy link
Contributor

siuying commented Dec 24, 2012

If you replace the loc with @loc, the code below should work in run_after.

You need to use @, because it will create an instance variable in the
object, and thus keep it from being released by GC.

Ben Taylor 於 2012年12月24日星期一寫道:

I'm currently spicing up one of my RubyMotion apps with BubbleWrap. A
little bit of code I have works fine with GCD but crashes using
App.run_after. My knowledge of the Objective C threading model and Timers
vs GCD is limited, so I'm not sure whether this would break a bunch of
existing code.

Anyway, my example:

loc = @mapView.region.center

Dispatch::Queue.main.after 0.4 do
new_loc = @mapView.region.center
if loc == new_loc
self.updateLocation
end
end

The change to BubbleWrap would be super quick, though I haven't made the
change and tested it. Just wanted to check it was a sane thing to do.


Reply to this email directly or view it on GitHubhttps://github.com//issues/180.

@taybenlor
Copy link
Author

So why does this work fine with GCD, but not using App.run_after?

@taybenlor
Copy link
Author

And, if it does work fine with GCD, but not with an NSTimer - doesn't that make a great cause for switching to GCD over the NSTimer?

@siuying
Copy link
Contributor

siuying commented Dec 24, 2012

This depends on the implementation of the Dispatch. In any case, the loc is
a local that is not retained, and it is not safe to use in block, even it
work now, it will cause you trouble some day.

Ben Taylor 於 2012年12月24日星期一寫道:

So why does this same example work fine with GCD, but not using
App.run_after?


Reply to this email directly or view it on GitHubhttps://github.com//issues/180#issuecomment-11660457.

@taybenlor
Copy link
Author

Is there something in the RubyMotion docs explaining this? It massively violates the way blocks work in Ruby.

  • Ben

On Tuesday, 25 December 2012 at 12:19 AM, Francis Chong wrote:

This depends on the implementation of the Dispatch. In any case, the loc is
a local that is not retained, and it is not safe to use in block, even it
work now, it will cause you trouble some day.

Ben Taylor 於 2012年12月24日星期一寫道:

So why does this same example work fine with GCD, but not using
App.run_after?


Reply to this email directly or view it on GitHubhttps://github.com//issues/180#issuecomment-11660457.


Reply to this email directly or view it on GitHub (#180 (comment)).

@siuying
Copy link
Contributor

siuying commented Dec 24, 2012

That is not the reason of choosing GCD vs NSTimer. Generally GCD is a lower
level implementation than that of foundation classes. Class like
NSOperation are implemented using GCD.

Ben Taylor 於 2012年12月24日星期一寫道:

And, if it does work fine with GCD, but not with an NSTimer - doesn't that
make a great cause for switching to GCD over the NSTimer?


Reply to this email directly or view it on GitHubhttps://github.com//issues/180#issuecomment-11660480.

@taybenlor
Copy link
Author

No that's fine. I'm more concerned about the fact that you're claiming blocks are no longer closures.

@siuying
Copy link
Contributor

siuying commented Dec 24, 2012

I don't sure are there any official documentation about this. But yes, the
GC of rubymotion is not like regular ruby. I hope it will be fixed someday.

Ben Taylor 於 2012年12月24日星期一寫道:

Is there something in the RubyMotion docs explaining this? It massively
violates the way blocks work in Ruby.

  • Ben

On Tuesday, 25 December 2012 at 12:19 AM, Francis Chong wrote:

This depends on the implementation of the Dispatch. In any case, the loc
is
a local that is not retained, and it is not safe to use in block, even
it
work now, it will cause you trouble some day.

Ben Taylor 於 2012年12月24日星期一寫道:

So why does this same example work fine with GCD, but not using
App.run_after?


Reply to this email directly or view it on GitHub<
https://github.com/rubymotion/BubbleWrap/issues/180#issuecomment-11660457>.


Reply to this email directly or view it on GitHub (
#180 (comment)).


Reply to this email directly or view it on GitHubhttps://github.com//issues/180#issuecomment-11660616.

@siuying
Copy link
Contributor

siuying commented Dec 24, 2012

Refer this blog.blazingcloud.net/2012/07/16/rubymotion-block-scope-bug/

It should have been fixed. I remember I've encountered some similar issue
in a different case and reported them.
Please report any issue if you find some unexpected behavior.!

Ben Taylor 於 2012年12月24日星期一寫道:

No that's fine. I'm more concerned about the fact that you're claiming
blocks are no longer closures.


Reply to this email directly or view it on GitHubhttps://github.com//issues/180#issuecomment-11660681.

@siuying
Copy link
Contributor

siuying commented Dec 24, 2012

About this issue, would you please create a test case that reproduce it?

Ben Taylor 於 2012年12月24日星期一寫道:

No that's fine. I'm more concerned about the fact that you're claiming
blocks are no longer closures.


Reply to this email directly or view it on GitHubhttps://github.com//issues/180#issuecomment-11660681.

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

No branches or pull requests

2 participants