locked
What is the best way to wait for Async operations to complete

Answers

All replies

  • I tried the sample code available (refer URL above), it behaves the same. Code in the chains does not get executed. As I mentioned above it creates the 'bar.txt' file.

    Is there an alternate way to accomplish the same.

     

    Thanks

    PB


    • Edited by __PB Friday, October 14, 2011 8:24 PM
    Friday, October 14, 2011 6:39 PM
  • Try writing to the pictures library instead (off course you will need to add permissions for pictures library in the appx manifest):

    StorageFolder^ item = KnownFolders::PicturesLibrary;
    

    After making the above change it works for me.

    It seems for DocumentsLibrary you need to do something else in the manifest.  I will find out more about that but for the time being the above should unblock you.

    Thanks
    Raman Sharma, Visual C++ 

    Friday, October 14, 2011 10:18 PM
  • After the change, it creates an empty file, but it did not write anything. 


    CAT
    Friday, October 14, 2011 10:55 PM
  • Could you be kind enough to provide a little more background on your application?

    How is the WriteFileSample() function being executed? Is it being executed as part of the UI callback (non-blocking) or in a single thread (blocking)?

    Friday, October 14, 2011 11:12 PM
  • Oh I see, in this case WriteFileSample is called with blocking = true and it is called inside the UI thread. Could you provide some insight?

     


    CAT
    Saturday, October 15, 2011 12:56 AM
  • What you seem to be encountering here is a deadlock. Let me elaborate a bit... (I'm assuming that you are working of some of the existing Metro templates or samples)

    The asynchronous calls that are chained run under the same context which executed them. In this scenario since we are calling the asynchronous methods within the UI thread, they will be expected to run on the same. However in this example, because we are blocking on the UI thread (CoWaitForMultipleHandles is executed when blocking == true) subsequent asynchronous chained callbacks never get executed (because no message pumping is ocurring on the UI thread). This in turn prevents both calling the "ordered" inner async lambdas and eventually singaling the completion event (SetEvent) which the UI thread relies on to continue.

    In other words, while WriteFileSample() (through CoWaitForMultipleHandles) is waiting on sigEvent to get set by the streamFlushOp AsyncOperationCompletedHandler, createStorageFileOp's AsyncOperationCompletedHandler is waiting on the UI thread to continue with the message loop before executing.

    In general, blocking a UI thread is always a really bad idea. What asynchronous calls are trying to accomplish is the need to not block the UI thread at all. Any time that we do so, we get into either hangs or deadlocks which sometimes are pretty nasty to debug.

     

    However, coming back to the solution... Have you tried calling the method without blocking the UI thread?

    Saturday, October 15, 2011 4:16 AM
  • >> Have you tried calling the method without blocking the UI thread?

    I have tried it and it works for me.  Off course I need to change from Documents to PictureLibrary.

    Saturday, October 15, 2011 4:41 AM
  • Regarding the PictureLibrary change, could it be that you might be missing the document library capability?
    Saturday, October 15, 2011 7:07 AM
  • I think even after I add the documentlibrary capability, I still need to add some file association thing to my manifest for ".txt" files.
    Saturday, October 15, 2011 2:14 PM
  • Without blocking it works, then the question is why do we need that code (you may say, incase you want to call it from non UI thread). But my use case is like this

     

    for all pictures in my array

         Process a picture; // here I use internal data structures to store some processed info

         WriteToFile(); // this function should consume data from internal data structures

                             // and write my picture to external disk

    end for

    in this use case to save memory I use only one buffer, I need finer control on 'WriteToFile()'. I mean to say I want my for loop to proceed with next image after 'WriteToFile(); is done.

    What is the best way to accomplish the above? (one solution is to move the processing to 'WriteToFile', but is there other solution or some kind of Design Pattern you guys use at MSFT)



    • Edited by __PB Monday, October 17, 2011 5:32 PM
    Monday, October 17, 2011 5:28 PM
  • It seems what you want is a way to wait.  You might want to look at this:

    http://code.msdn.microsoft.com/windowsapps/Windows-8-Asynchronous-08009a0d

    It's a better way to do asynchronous programming in C++ and actually provides some wait semantics as well.

    Thanks
    Raman Sharma, Visual C++ 

    Monday, October 17, 2011 6:58 PM
  • Thanks Raman, will try it out.

    PB

    Monday, October 17, 2011 10:45 PM