Discussion:
[NSButton state] must by used from the main thread
(too old to reply)
Tamas Nagy
2017-09-26 08:16:46 UTC
Permalink
Hi there,

XCode 9’s new main thread checker feature found the possible issue mentioned on the subject line. Indeed there is a background thread that check’s the state of an NSButton subclass, but I’m wondering if this is a real issue - I understand the problems with changing the UI from a background thread, but “state” of the NSButton is a NSInteger property, so that should be safe to read from a background thread, right?

Thanks in advance!

Best,
Tamas
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.nar
Quincey Morris
2017-09-26 08:35:20 UTC
Permalink
Post by Tamas Nagy
but “state” of the NSButton is a NSInteger property, so that should be safe to read from a background thread, right?
Not necessarily. If the setter is thread-unsafe, then it’s possible that the getter may retrieve an incorrect value.

It’s not clear whether Apple has audited methods to determine thread safety (so that such reported errors represent an actual pitfall), or whether there is a general restriction on settable properties of UI objects. Either way, prudence dictates that you heed the warning and change the code.

Now that I think about it, getting a button state on a background thread does seem like an odd thing to do. Except in the simplest of cases, it does seem to open up the possibility of race conditions, since the “when” of the value might matter, relative to the timing of the surrounding code.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.n
Tamas Nagy
2017-09-26 08:57:14 UTC
Permalink
Makes sense, thanks Quincey.

Best,
Tamas
Post by Quincey Morris
Post by Tamas Nagy
but “state” of the NSButton is a NSInteger property, so that should be safe to read from a background thread, right?
Not necessarily. If the setter is thread-unsafe, then it’s possible that the getter may retrieve an incorrect value.
It’s not clear whether Apple has audited methods to determine thread safety (so that such reported errors represent an actual pitfall), or whether there is a general restriction on settable properties of UI objects. Either way, prudence dictates that you heed the warning and change the code.
Now that I think about it, getting a button state on a background thread does seem like an odd thing to do. Except in the simplest of cases, it does seem to open up the possibility of race conditions, since the “when” of the value might matter, relative to the timing of the surrounding code.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-
Gary L. Wade
2017-09-26 14:05:11 UTC
Permalink
If you have an issue with one API reporting such an issue, write a radar, as I did for getting the application’s delegate when I encountered it. For a button’s state, however, there may be a better way to pass that value to a background thread, especially if the button should be setting a value somewhere else that can be atomic and which decouples your background thread from the UI.
--
Gary L. Wade
http://www.garywade.com/


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email se
Jens Alfke
2017-09-26 15:19:04 UTC
Permalink
Post by Tamas Nagy
“state” of the NSButton is a NSInteger property, so that should be safe to read from a background thread, right?
No. You can’t tell anything about a property’s implementation from its return type. You’re assuming it’s a synthesized getter, but there’s no reason it couldn’t be a custom method that does arbitrary computation before returning the value, and there’s no way to know whether that work is thread-safe or not.

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-i
Quincey Morris
2017-09-26 15:53:40 UTC
Permalink
Post by Jens Alfke
You’re assuming it’s a synthesized getter, but there’s no reason it couldn’t be a custom method that does arbitrary computation before returning the value, and there’s no way to know whether that work is thread-safe or not.
It is, in a sense, “even worse” than that. Even with a synthesized getter, you might get a bad value, if it’s a non-synthesized, non-trivial setter. For example, it’s possible to pass an arbitrary number to the NSButton.state setter, but the getter is supposed to return one of three values (on, off, mixed). If the setter stores the input value transiently, before replacing it with the legal equivalent, that could lead to a failure in using the getter.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent

Continue reading on narkive:
Loading...