Inherit thread affinity from base types and members #231

Activity

1. AArnott commented on Apr 4, 2018

   

   Andrew Arnott (AArnott)

   on Apr 4, 2018

   Member

   More actions

   Members derived from a member that requires the main thread should also have a main thread requirement

   By a derived member are you talking about an override member?

   Members which have a main thread requirement due to inheritance should not report a warning if they are missing a ThrowIfNotOnUIThread call

   I disagree. There is no guarantee that the caller has the threading analyzers applied to their project with the right analyzer turned to warning/error. At runtime something that requires the UI thread should still throw if it's not called on the UI thread in order to prefer throwing exceptions over deadlocking.
2. Andrew Arnott (AArnott)

   added

   analyzers

   on Apr 4, 2018
3. sharwell commented on Apr 4, 2018

   

   Sam Harwell (sharwell)

   on Apr 4, 2018

   ContributorAuthor

   More actions

   By a derived member are you talking about an override member?

   • override: Yes
   • Explicit interface implementation: Yes
   • Implicit interface implementation: Probably, but could be persuaded otherwise and may not be necessary. Biggest advantage would be code implementing an interface provided by some service, where the service only ever calls into the interface from the UI thread. By marking the interface and having it propagate to implementations, the analyzer could assume the entry point to each method in the implementation is on the UI thread.
4. sharwell commented on Apr 4, 2018

   

   Sam Harwell (sharwell)

   on Apr 4, 2018

   ContributorAuthor

   More actions

   I disagree. There is no guarantee that the caller has the threading analyzers applied to their project with the right analyzer turned to warning/error. At runtime something that requires the UI thread should still throw if it's not called on the UI thread in order to prefer throwing exceptions over deadlocking.

   This is fine, but if the behavior is kept it should use a different diagnostic ID. Otherwise it's an overwhelming source of noise for code that defines hundreds or thousands of event handlers for UI events.
5. AArnott commented on Apr 4, 2018

   

   Andrew Arnott (AArnott)

   on Apr 4, 2018

   Member

   More actions

   Event handlers I don't mind removing the requirement from under the conditions you proposed. It's members that are accessible in other ways that I think should still defend themselves from improper calling.
6. sharwell commented on Apr 4, 2018

   

   Sam Harwell (sharwell)

   on Apr 4, 2018

   ContributorAuthor

   More actions

   That seems more relevant for a library or application with a public API. For a contained application, it's just noise (all the entry points to affinitized code would be analyzed separately).

   👍React with 👍1Reacted by Andrew Arnott
7. Andrew Arnott (AArnott)

   added a commit that references this issue on Jan 5, 2024

   Bump powershell from 7.3.9 to 7.4.0 (microsoft#231)

   ...

   4289461