-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[ReactiveUI 6.4.x] AsyncTask not running on background thread in WPF application #813
Comments
The SynchronizationContext is probably captured when you created the ReactiveCommand using async / await syntax. This will result in the continuations (lines after the awaits) being run on the dispatcher thread. Please note that the actual work ( try to use the Task directly:
edit: furthermore: The SubscribeOn call can be omitted. Subscribing to an ReactiveCommand, will run on the RxApp.MainThreadScheduler by default. I think the SubscribeOn can also be omitted. @paulcbetts please correct me if I'm wrong.
|
Thanks Rik for you answer. I should have mentioned that I tried using the task directly and I got the same result. The SO answer also mentioned that SubscribeOn & ObserveOn are not required, but having them or not does not change the end result. Thanks for pointing out that the async methods inside GetData() are executed on a bg thread, but I would like to execute GetData in a bg thread as well. This is just a simple example. |
I think you may be misreading my SO post, which actually says the opposite, that RxUI 6.x does not guarantee it will be run on another thread, if the async method below it is badly written. In this case, because HttpClient is doing blocking operations when it shouldn't, you need to wrap it in a Task.Start |
Thanks for you answer. I see now what you meant on your SO answer, sorry for that. Going back to the latest reply: What do yo mean by "if the async method below it is badly written"? I do not quite get why this is the case. I am sorry if I am missing something obvious. If my GetData method (which is just an example, not my real code) does a lot of heavy computations and/or many IO operations, it would be great to tell RxUI to execute it in a new task. How can I achieve that without Task.Start? Is it possible? How can I tweak this GetData example so it is no "badly written" anymore? Thanks |
So, HttpClient as I recall, does something kind of dumb - while it guarantees that the actual request is done on another thread, the DNS lookup often ends up being on the UI thread, before it calls an async method, so you lock up. In general, async is just a handshake between two methods, "I promise not to block the UI thread", but that promise doesn't have teeth - badly written methods can totally block the calling thread.
Using Task.Start is an entirely reasonable way to guarantee that code run on the background thread |
Ok, got it now. I thought I was missing something different. I was under the wrong impression that RxUI was in charge of executing in the BG those commands that were created using CreateAsyncTask (which, BTW, would be a nice feature). Thanks for your answers. |
Hello,
I am not sure if this is a bug in my code, a rxui bug or if I am just misunderstanding the expected behavior of the framework.
I have pretty much the same problem/issue posted on this SO question. Basically, I am not able to automagically run IO operations in a background thread. I am overcoming this by manually firing off new tasks for each IO operation, but I would like to stop doing that as (if I understood correctly) it "should not" be necessary.
I have pasted some code that I am using to track threads.
C# code
XMAL code
According to Paul's answer, "ReactiveCommand should guarantee that even async operations that accidentally burn CPU before running an async op are forced onto background threads". However, that's not what I am seeing. My app runs always on the UI thread.
Now the questions. Is this the expected behavior? Is my sample code wrong? Is there a known issue in the rxui code base?
Thanks
The text was updated successfully, but these errors were encountered: