4 ms·
On a related note, I really dislike the dispatcher paradigm, especially with the inclusion of async-await. For good performance of IO async calls you usually w
by mhomde 11y ago
On a related note, I really dislike the dispatcher paradigm, especially with the inclusion of async-await.
For good performance of IO async calls you usually want to call .ConfigureWait(false), otherwise it will wait for the UI context to switch back to, you might even risk thread starvation.
But now each async call is a potential switch out of the UI thread and certain crasch down the road, meaning you have to put Dispatcher.HasThreadAccess checks on all your UI methods. It just feels... clunky and unnecessarily explicit.
In my opinion UI controls should be able to handle switching to UI context themselves and not crash the whole program, or if nothing else you should be able to annotate methods as UI threads rather than the clunky HasThreadAccess syntax.
There's also these annoying "barriers" that you can't do certain UI stuff on background threads without some ugly hacks, like creating and working with images.
The Dispatcher is cool for being able to prioritize UI operations though
- zamalek 11y ago> the dispatcher paradigm is one of the thing I dislike the most about coding UI stuff in .Net It inherits it from Windows. As far as I know, most GUIs have a dispatcher because <technical reasons>. I definitely think that there could have been a better way to solve the problem (method interception), however, I think that TPL does add value. In your case you cited intense IO as one reason to call `.ConfigureAwait(false).` The thing is: you have made a conscious decision to not return to the UI thread and therefore are more likely to tread carefully when writing the remainder of the method. `.ConfigureAwait(false)` declares "dragons be here." Previously someone who didn't know better would update the UI from the wrong thread, weird things happen and they don't know why. Here's something to make things simpler for you: https://gist.github.com/jcdickinson/f875229e671710cf1b34 https://gist.github.com/jcdickinson/f875229e671710cf1b34
- asveikau 11y ago> It inherits it from Windows. As far as I know, most GUIs have a dispatcher because <technical reasons>. This is a kind of lame elision. The classical Windows UI threading model is that every window has an owning thread [the thread it was created on], and that owning thread is supposed to drain its message queue periodically. You can send messages to another thread's object [either in blocking, via SendMessage, or enqueue without blocking for result, via PostMessage].