I am developing a project for BB. The application works with the network and sends / receives data via HTTP. Now I use the queue and queue manager. Manager starts with a background thread and works in while (true) loop, checking the queue for new transactions to the server. If the queue is not empty, then the transaction is executed, otherwise the manager goes to sleep for 200 ms.
The process of the transaction as follows:
- Runs another thread (using the Runnable), which opens a connection to the network and first thread waiting for background thread or timeout (and for that we need a loop), which we set.
- If the connection is established, then starts another thread (using the Runnable), which runs getResponseCode (), and first thread waiting for background thread or timeout (and for that we need a loop), which we set.
Before it, we showing popup window with wait-rotating-image, and after it is removed. It synchronized via Application.getEventLock ().
Iit unstable sometimes and thread sleeps for a long time ignore timeout-waiting-loop.
I would like to know how valid such an approach, what advice and best-practice is, what is your experience?
I use 4.5, 4.6, 4.7 and 5.0.
The lock returned by Application.getEventLock() should only be used for code that modifies the UI or UI components - it's the lock used by the event dispatcher. You should not be using it for background tasks such as HTTP processing. If you want to synchronize that code, it would be best to just create your own lock object.
You do not need that many threads, your EDT (event dispatch thread a.k.a main thread) should insert he job (some runnable class) into a queue and use wait/notify to inform a dedicated worker thread, that is responsible for network transaction, to check the queue.
The worker thread will be responsible for opening connection, writing to connection and reading from it.
For information about wait/notify mechanism check out:
A simple scenario using wait() and notify() in java
Due to the fact that you can't update the UI using the worker thread, Once the network transaction is completed you can update the UI layer using InvokeLater
For more details go to http://www.blackberry.com/developers/docs/5.0.0api/net/rim/device/api/system/Application.html#invokeLater(java.lang.Runnable)
you can set a timeout in the HTTPConnection itself, but if you don't want to rely on that mechanism, you can schedule a TimerTask that will execute after some time and handle the timeout in case no response is received.
Once the response is received all you need to do is cancel the TimerTask so that the timeout will not be triggered.
Check out http://www.blackberry.com/developers/docs/4.0api/java/util/TimerTask.html
Related
As we know, dart is a single-threaded language. So according to the document, we can use Futrure/Stream to implement a async opetation. It sends the time-consuming operation to the Event Queue.
What confused me is where the Event Queue working on. It is working on the dart threat? if yes, it will block the app.
Another question is Event Queue a FIFO queue. If i have two opertion, one is a 1mins needed networking request, the other is a click event. The two operation will send to the Event Queue.
So if the click event will blocked by the networking request? Because the queue is a FIFO queue?
So where is the event queue working on?
Thank you very much!
One thing to note is that asynchronous and multithreading are two different things. Dart uses Futures and async/await to achieve asynchronicity, but Dart is still inherently a single-threaded language.
The way it works is when a Future is created (either manually or via calling an async method), that process is added to an event queue, as you read. Then, in the middle of all the synchronous execution, whenever there is a lull, the event queue can take priority. It can then go through the processes and figure out if any of the Futures have been completed. If so, the result is passed along to any other asynchronous processes that are waiting on that resource, if any.
This also means that, yes, if your program hangs in the middle of an asynchronous operation (with the easy example of an endless loop via while (true) {}), it will freeze the entire program, including the synchronous code and other asynchronous processes still waiting to resolve (even if the conditions allowing them to resolve have already occurred).
However, in your case, this won't be an issue. If you fire an asynchronous process in the form of a network request followed by another in the form of a "click event" (not sure what you're referring to, but I'll assume it's asynchronous as well), they will both be added to the event queue in that order. But if the click event resolves before the network request, the event queue will merely recognize that the network request Future has not yet resolved and will move on to the click event that has.
As a side note, it's worth noting that Dart does have a multi-threading capability, albeit in a fairly roundabout way. Dart has something called an Isolate, which isn't a thread but a completely separate child program. This means that the Isolate cannot access any of the same data in memory as the root program itself. However, data can be passed between the two using SendPorts and ReceivePorts. This makes using Isolates slightly more complicated than threads, but it also means that, if no memory is shared, it virtually eliminates race conditions based on which thread accesses the memory first.
Imagine this action:
public async Task<ActionResult> MyAction(){
var result = await MyMethodAsync();
return View(result);
}
I understand that by making the action async, you release the thread executing the action back to the thread pool while MyMethodAsync() executes, so that it can be used to serve other HTTP requests.
Now I'm wondering: then what thread executes MyMethodAsync()? I'm guessing it's not another thread from the thread pool, since that would defeat the purpose of async actions. Is it just a brand new thread that is created, started and destroyed when the HTTP response is finished?
No it still comes from the thread pool, and it does not defeat any purpose.
Async comes becomes valuable during blocking operations, like accessing the disk or network, anything that is not cpu-bound (i.e., operations that are I/O (Input/Output) bound).
The thread is returned to the pool only so that it doesn't have to wait for the blocking operation to complete before it can help service another HTTP request.
Once the blocking operation is complete, another worker thread is grabbed from the pool.
This can help to counteract something called thread pool starvation. Each thread pool only spins up so many threads, and spinning up more is expensive. Sometimes it is the case that a web server can be tied up with many threads waiting for blocking operations to complete, so new requests have to wait for a new thread, meaning they have to wait for someone else's blocking operation. With async, a thread that is waiting on a blocking operation can be returned to the pool so that it can service other (possibly CPU-bound) requests.
Read this: http://msdn.microsoft.com/en-us/library/ee728598(VS.100).aspx
...and then read this: http://blog.stephencleary.com/2013/11/there-is-no-thread.html
I understand that another thread is grabbed from the pool once the
blocking operation is done, but what I don't know is exactly what
thread executes the blocking operation itself.
No thread executes the blocking operation. The CPU is waiting on another device -- like the network card, or the disk controller, to return output.
Threads are CPU-bound artifacts, as is RAM, since it operates over a buss according to the CPU clock rate. There are other devices in the machine like USB, network card, disks, etc. These other devices are I/O bound because they are input/output devices.
I am connecting to a server as a client using TCPSocket. The main point is to keep connection open and send there or receive from there messages as soon as they arrive.
There are no problems with sending messages, but doing socket.recv(n) in main thread when server has nothing to respond with, makes client's main thread to pause while waiting for data.
What is the good practice to work with persistent connections in Ruby to prevent main thread blocking?
Let's suppose that extra thread should be used. Where to insert this thread initialization in Rails app? Make a worker process?
Receiving data on a dedicated thread is certainly possible. But also consider using IO#select or IO#read_nonblock. (TCPSocket is a subclass of IO.) If you are waiting for data to come from any one of several sockets, IO#select would be ideal. If you are doing some other processing on the main thread, but also need to remain responsive to input coming in from a socket, you can call IO#read_nonblock at intervals.
I have problem suspending the current task being executed, I have tried to set NSOperationQueue setSuspended=YES for pausing and setSuspended=NO for resuming the process.
According to apple docs I can not suspend already executing task.
If you want to issue a temporary halt to the execution of operations, you can suspend the corresponding operation queue using the setSuspended: method. Suspending a queue does not cause already executing operations to pause in the middle of their tasks. It simply prevents new operations from being scheduled for execution. You might suspend a queue in response to a user request to pause any ongoing work, because the expectation is that the user might eventually want to resume that work.
My app needs to suspend the time taking upload operation in case of internet unavailability and finally resume the same operation once internet is available. Is there any work around for this? or I just need to start the currently executing task from zero?
I think you need to start from zero. otherwise two problems will come there. If you resume the current uploading you cant assure that you are not missed any packets or not. At the same time if the connection available after a long period of time, server may delete the data that you uploaded previously because of the incomplete operation.
Whether or not you can resume or pause a operation queue is not your issue here...
If it worked like you imagined it could (and it doesn't) when you get back to servicing the TCP connection it may very well be in a bad state, it could have timed out, closed remotely...
you will want to find out what your server supports and use the parts of a REST (or similar) service to resume a stalled upload on a brand new fresh connection.
If you haven't yet, print out this and put it on the walls of your cube, make t-shirts for your family members to wear... maybe add it as a screensaver?
I am working on an app, which uploads native contacts to server then get responses(JSON, a contact list that already installed the app). When native contacts are large enough, server response will be slow and unstable. And user cannot do other things. so I put network request into background thread. every time I will upload 100 contacts, do some tasks , then next 100 contacts until loop finish.
But in running, the result is not as expected. background thread is running, it keeps to request server. UI thread is blocked, I still cannot do anything.
is this cause a long loop in background thread? Although I have 2 thread, but they will compete CPU resources(test device is iPod, 1 core. And I think this may not related core numbers)?
Could anyone tell me hints on how to handle this kind of scenario? Thanks in advance!
Update:
I have found the root cause. A global variable in App delegate is set to wrong value, therefore UI behavior is weird. I found this by comment all network request method. So this problem is not related with multiple threading. Sorry for the bother.
I think there needs to be some clarification as to how you are performing the network operations.
1st, NSOperatiomQueue deals with NSOperations, so you are presumably wrapping your network code in an NSOperation subclass.
2nd, are you using NSURLConnections for your networking code?
3rd, is the blocking part the NSURLConnection or you delegate callback for NSURLConnection?
1 thing to note is that plain ol' NSURLConnections are implemented under the hood multithreaded. The object is placed into your main threads run loop by default (when run from the main thread), but the object is just a wrapper that handles callbacks to the delegate from the lower level networking code (BSD sockets) which happens on another thread.
You really shouldn't be able to block your UI with NSURLConnections on the main thread, unless A) you are blocking the thread with expensive code in the delegate callback methods or B) you are overwhelming your run loop with too many simultaneous URL connections (which is where NSOperationQueue's setMaxConcurrentOperationsCount: comes into play)