I try to understand the documentation of suspendCoroutine.
In this function both Continuation.resume and Continuation.resumeWithException can be used either synchronously in the same stack-frame where the suspension function is run or asynchronously later in the same thread or from a different thread of execution.
This sounds to me like: "resume can be used everywhere".
Is there anything left, I am not aware of?
Update for the closing gang having problems to understand anything: The documentation list three restrictions:
synchronously
asynchronously
in other thread
The question is: why are the restrictions enumerated, if the sum of all restricitons is no restriction?
Yes, you can resume a continuation from anywhere.
It's an error to try and resume the same continuation more than once, though.
If you call resume immediately, during the call to suspendCoroutine, the coroutine does not suspend.
If you don't call resume immediately, that's what results in a coroutine suspension. The suspended coroutine then resumes when you later call resume from some other control flow.
The continuation you receive from suspendCoroutine is intercepted by the context's dispatcher. When you resume a suspended coroutine via an intercepted continuation, the coroutine resumes on the dispatcher, rather than running on the thread from which you resumed it.
Related
To illustrate, the docs for the suspend function delay says:
Delays coroutine for a given time without blocking a thread and resumes it after a specified time.
This suspending function is cancellable. If the Job of the current coroutine is cancelled or completed while this suspending function is waiting, this function immediately resumes with CancellationException. There is a prompt cancellation guarantee. If the job was cancelled while this function was suspended, it will not resume successfully.
In this description, do waiting and suspended mean the same thing? Or is a suspend function that is waiting in a different type of state from when it's suspended?
There is no specific meaning for "waiting" in this case (to my knowledge), I would say it could definitely be read as "suspended". Both parts of this doc refer to the same state.
In the task-based asynchronous pattern - while calling a method we use the await keyword, i.e.;
await client.OperationName(parameterlist)
The await keyword suspends the execution of the method until the awaited task completes.
"AWAIT SUSPENDS THE EXECUTION OF THE METHOD"
Then how does it differ from synchronous calling?
I think the term "suspends" is a bit confusing. To be more precise - calling await on an async method yields the execution to the calling method, which means it won't wait for the method to finish executing, and won't block the thread. Once it's done executing in the background, the method will continue from where it stopped.
With a synchronous method - the thread's execution won't continue until the method finishes executing, which will block.
From MSDN:
Async methods are intended to be non-blocking operations. An await
expression in an async method doesn’t block the current thread while
the awaited task is running. Instead, the expression signs up the rest
of the method as a continuation and returns control to the caller of
the async method.
Read Stephen Cleary's articles on this stuff. They are very informative and should clear up any confusion or questions you have.
http://blog.stephencleary.com/2012/02/async-and-await.html
http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
In a synchronous scenario, if a method is long-running the thread blocks while waiting for the method's execution to complete. This may lead to scalability/performance issues. Conversely, in an asynchronous scenario (async/await) the thread is released until the awaitable part(s) of the method has completed.
This is the awaitable part of your method. The method's execution is suspended here until the await is complete.
await client.OperationName(parameterlist)
I have the following sub in my program:
public sub RunThis()
Me.Hide()
NEWFORM.Show()
Dim t = New Thread(Sub() Me.printToPowerPoint(saveLocation, printlist))
t.SetApartmentState(ApartmentState.STA)
t.IsBackground = True
t.Start()
While t.isAlive
end while
NEWFORM.close()
Me.Close()
end sub
Running this my program hangs. Does anyone have a solution for this problem.
I am new to threading.
As you probably know, in WinForm projects, the UI can only be dealt with from a single thread. This is affectionately known as the UI thread. That's why, any time you need to access or modify a UI element, you must call the control or form's Invoke method. The Invoke method causes the given delegate to be run on the UI thread. However, doing so will not interrupt any processing that is already being performed by the UI thread. If the UI thread is currently busy, when you call Invoke, it will hang until the UI thread is no longer busy, then it will execute the given delegate.
So, in your code, you are starting a new thread which inside it is trying to invoke a method back on the UI thread. However, immediately after starting the new thread, you then enter a loop which keeps the UI thread busy until the other thread is done. So, when your new thread invokes back to the UI thread, the UI thread is busy and both threads are effectively hung forever.
DoEvents is a keyword you can call from within a lengthy process or loop in the UI thread to signal that you want to, essentially, pause your current processing thereby freeing up the UI thread to process any waiting window messages (painting events, click events, invoke requests, etc.). As soon as all those pending window messages are processed, it will return to doing whatever the next statement is after you called DoEvents. Therefore, if calling DoEvents inside the loop causes it to work properly, that means that your new thread must be invoking back onto the UI thread, or waiting for some other window message to be processed before continuing.
Calling DoEvents is dangerous and widely panned as being bad practice. Typically, if you need to call DoEvents, it's a sign that you need to rethink your design. Usually there is a better way to do what you are doing.
In your case, it looks like starting the new thread is utterly pointless. Unless you have abbreviated you code, it appears that as soon as you start the new thread, you simply put the UI thread on hold waiting for the other thread to finish. If that's the case, it would make much more sense to simply do the work on the UI thread itself rather than starting a new one. In the code you provided, no two threads will ever be effectively be doing processing at the same time, so it's no better than a single thread.
Does the following code run on the main thread? Does "main queue" refer to the main thread?
dispatch_async(dispatch_get_main_queue(),
^{
// Some code
});
The async part of dispatch async vs sync is different than concurrent vs serial. Async means that the function returns immediately, sync means that it'll wait until the block is executed. Since the main thread/queue is serial, things are going to get executed in order - I believe this means that since you're asking it to async dispatch on the same thread you're dispatching from, it'll return immediately, wait till the end of the current run loop and anything else in the queue, and then execute your block.
This is more useful for inside a queue than it is on the main thread - you can process your data, let the UI know to update, and continue processing without waiting for everything to redraw, etc. That's why you'll often see a dispatch_async call to the main thread inside another dispatch_async(concurrent queue) instead of just a dispatch_sync.
Yes. From Apple developer site:
The dispatch framework provides a default serial queue for the
application to use. This queue is accessed via
dispatch_get_main_queue().
This is documented in multiple places, including the docs for dispatch_get_main_queue() itself. The Concurrency Programming Guide says:
The main dispatch queue is a globally available serial queue that executes tasks on the application’s main thread.
If I use a performSelectorOnMainThread call inside a detached thread, when does the main thread execute the request? Does it do so immediately after it finishes the current main thread operation, or is there some other type of hierarchy that determines when the performSelectorOnMainThread call executes?
It executes on the main thread on the next iteration of the main thread's run loop.
Quoting Apple's documentation:
This method queues the message on the run loop of the main thread using the default run loop modes—that is, the modes associated with the NSRunLoopCommonModes constant. As part of its normal run loop processing, the main thread dequeues the message (assuming it is running in one of the default run loop modes) and invokes the desired method.