Is it safe to call these methods on the UI thread or should it be done in the background (as is the case with query())? In other words, is it possible that calling these on the UI thread will result in an ANR?
It is safe as the DownloadManager performs the actual tasks on a background thread internally.
The download manager will conduct the download in the background, taking care of HTTP interactions and retrying downloads after failures or across connectivity changes and system reboots.
Source
Related
I am trying to understand what happens to a thread when it is waiting for a http response from remote server.
Let's say at one point in time n processes are running. The OS based on its thread scheduling algorithm will try to run every thread (Let's say on round robin fashion). Let's say one out of n thread has initiated a http request and waiting for response from remote server. Will this thread keep on getting its turn on cpu core? or is there some interrupt sort of mechanism which will notify the thread if it is ready to run? If interrupt sort of mechanism is present, then what is the benefit of using asynchronous programming? at-least from CPU utilization perspective.
Is the above thing language dependent? If yes, what is the difference between java vs nodejs vs python ...
I am trying to understand What happens to a thread when it is waiting
for a http response from remote server.
Well, the thread will wait for the underlying TCP socket to receive data. HTTP is a high level protocol that uses blocking/nonblocking TCP connection. as itself, the thread doesn't wait for an "HTTP response" but rather to some available data for the socket to read.
Will this thread keep on getting its turn on cpu core?
If the thread waits for a TCP socket to be readable, the OS doesn't schedule this thread to run until some data is received. then the OS will schedule the thread to run in some point in the future. blocked thread is never schedule to run - the OS doesn't see the reason to do so, considering the fact that the thread has nothing to do.
Is the above thing dependent on language? if yes what is the
difference between java vs nodejs vs python ...
No. Each OS provides a C/C++ API for application to consume. Windows provides Win32, while Linux provides POSIX. every programming language wraps and binds these APIs and every "high level" call (such as connecting a socket) will eventually call the operating system APIs.
My understanding is asynchronous keyword is used for your program to continue executing instead of waiting for the forked process to complete, even in single core processors, as was the case with early computers we were able to multitask, hence this could be deduced that the resource allocation was done by cpu while trying to be as judicious as it could be, so using async allows your thread of execution to execute without waiting for the blocking task to get completed, otherwise, even though cpu will take turns in executing a thread but since your program is a single thread it will block.
I am using Qt5 on Windows7 platform.
In my current application I am using QtConcurrent to process all items in a container.
If I decide to exit the application, I am using: QFuture::cancel().
As per documentation http://doc.qt.io/qt-5/qfuture.html#cancel, not all async computations are canceled. Probably are canceled only the ones that are not yet started? And the running/ongoing computations are still allowed to continue to run?
If the above assumption is correct and QFuture::cancel() is not sufficient, then what should I do in order to stop also the running (ongoing) processing and exit the application gracefully?
You cannot pre-emptively and gracefully terminate asynchronous operations. The operations themselves must support co-operative cancellation.
In other words, it's impossible for any framework, library, or operating system to provide this functionality for you. You must handle cancelling operations that have already started yourself.
Maybe it's a simple question, but I don't get it. When should I use concureency in my javafx project? Is it right that I should use for every task, which do some action in the background, the Concurrency API? So every action in my controller class, which has nothing to do with the UI should be executed in a single task?
I really don't get it how to use this right....
Whenever you have a task that may take sometime to get executed or there is a possibility of delayed response, you do not want your JavaFX Application thread to wait for it, because, as long as the JavaFX Application thread waits for the response, the UI becomes unresponsive.
A few examples where you may want to use a background thread is :
An I/O operation
A web service call
From the JavaFX documentation :
Implementing long-running tasks on the JavaFX Application thread inevitably makes an application UI unresponsive.
On the other hand, if you have minor calculations or some task which can be completed in a jiffy (I am not sure if this is the correct word, but I hope you can relate to what I want to say) and will not put the JavaFX Application thread on wait, you can execute them on the same thread.
I am developing an application level VSTO 4 Addin for Microsoft Excel 2007 / 2010.
The result is a windows forms based DLL using .Net 4 Client Profile.
Now I have to use a legacy COM-DLL. It is no problem to set the reference and access the COM-Methods via COM-Interop from .Net.
But the the (synchronous) method I need to call can take a minute or longer to get back.
I know your answer:
Use a worker thread...
I have used The Task Parallel Library to put the long lasting operation in a worker task and keep the GUI (Excel) responding.
But: The inprocess COM-Call (in the worker task/thread) still seems to block my GUI-Thread.
Why? Is it because Excel is always running as STA (Single Thread
Apartment)?
How can I keep the Excel GUI responding?
Is there a way to make it really asynchronous?
Thanks for any answers,
Jörg
Finally, I've found an answer to this topic:
I've readed a lot about COM Threading Models and then spoke to the developer of the COM-DLL I am calling as an InProc-Server.
Together we changed the threading model of the COM-DLL:
OLD (blocking): Single-Threaded Apartment (STA), (ThreadingModel=Apartment)
NEW (working): Multi-Threaded Apartment (MTA), (ThreadingModel=Free)
Since we have our own synchronization mechanisms in the COM-DLL, there are no problems caused by the missing synchronization via the standard Windows message queue.
Problem was, that even the UI Thread was idle and even if it did DoEvents, the important windows messages (WM_Paint, etc.) were not delivered.
Now they are. The UI is responding at every time and the call to the COM-DLL is still done in a worker thread (as mentioned above, it's a ThreadPool thread which is used by the Task Parallel Library).
cache coherency protocol is well known in multi-cores context which is in the hardware low-level, however, we will meet the similar case in the application domain. Recently, I am working on a project which has two threads updating shared objects.
UI thread is responsible for
displaying and updating(via users
action) objects.
Background replication thread
periodically updates the shared
objects if something is changed by
other users.
since we have lots of objects(50,000~100,000), each thread have to copy part of objects into its own buffer, updating the shared objects is serial.
UI thread will not update object
each time when users update.
Background replication thread will
update objects immediately once
changes are found and then notify UI
thread to refresh.
So this brings the question, if there is a object updated by two threads, how is conflict sovled? Is there any common idiom to handle this case?
The simplest way to handle this is to use a mutex. The UI locks the mutex before it reads the value, then unlocks it afterwards. The background thread locks the mutex before it updates the value, then unlocks it afterwards.
You can have the update thread send a notification message to the UI telling it to reread the shared object, as you suggested.