<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Why .NET developers should check out the await system ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-341858/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-19T11:20:33-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[It depends on the scenario]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423979]]></link>
        <description><![CDATA[Stealing cycles from the UI thread isn't a big deal for the scenarios that await is designed for. For example, downloading a file, or waiting for a DB connection to return results. I agree 100% that it's a bad idea for CPU bound items, in which case you are recreating the problem that asynchronous operations are trying to avoid (responsive UI).Also, when you get to Silverlight, async stuff is mandatory in a lot of circumstances, so await is a much easier way of dealing with it. Await is much more useful to the Silverlight developer (or WPF developer trying to keep their code SL compatible) than the WinForms developer.J.Ja]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423979]]></guid>
        <dc:creator><![CDATA[Justin James]]></dc:creator>
        <pubDate>Tue, 01 Mar 2011 18:56:26 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[It really depends on the division]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423968]]></link>
        <description><![CDATA[I agree about Office and Windows CTPs and betas. I won't touch 'em except for research purposes (as in, &quot;what new features are here?&quot;). Even then, they are of poor quality much of the time. CTPs from Microsoft's .NET group, though, tend to be of excellent quality. The Parallel Extensions Library, for example, was real-world usable in 2008... two years before it got a version 1 release. Ditto for F#... what came out in .NET 4 was F# 2, I believe! In general, people seem happy with ASP.NET MVC CTPs and betas and such.J.Ja]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423968]]></guid>
        <dc:creator><![CDATA[Justin James]]></dc:creator>
        <pubDate>Tue, 01 Mar 2011 18:53:29 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[No more Tech previews for me]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423881]]></link>
        <description><![CDATA[I learned my lesson about CTPs with Office 2010. I had terrible support, bad advice when problems arose. When the problem couldn't be fixed it was marked resolved when it wasn't. The removal  software failed to remove the beta, so did following their advice to remove all versions of office via add/remove. I have a laptop with no working version of Microsoft Office and no version of Office will install because  the software thinks office is already on the machine. Call me when version 3.1 is ready.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423881]]></guid>
        <dc:creator><![CDATA[conceptual]]></dc:creator>
        <pubDate>Tue, 01 Mar 2011 12:39:18 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Easier to code a background worker and keep the UI responsive]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423790]]></link>
        <description><![CDATA[The point that Justin was making with await vs. the Background worker is that control is passed to the UI automatically while the function called with await finishes. A classic example is a waiting for things to load, e.g., let's say you're searching for something that takes a long time to retrieve.  While the data is being searched for and loaded, await lets the thread return to the UI without having to use the background worker or start up a new thread, create a callback, and then have to remember to call the BeginInvoke on whatever control you want to update (e.g., a listbox) to prevent cross-thread interaction.Having the thread return to the UI and auto-creating a second thread makes for easier code and allows the UI to remain responsive-- the user could cancel the search, close the program, or use some secondary function while waiting, all without having to get the annoying 'Program is not responding' message.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423790]]></guid>
        <dc:creator><![CDATA[ps2goat]]></dc:creator>
        <pubDate>Tue, 01 Mar 2011 09:57:03 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Benefit?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423761]]></link>
        <description><![CDATA[What's the real benefit of this? You're basically stealing cycles from the UI thread - which you don't want to do. That's why you're calling an asynchronous process. The &quot;Caution&quot; mentioned above is very real, and the fundamental reason why you shouldn't be doing this in the first place.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-341858-3423761]]></guid>
        <dc:creator><![CDATA[bluemoonsailor]]></dc:creator>
        <pubDate>Tue, 01 Mar 2011 09:16:20 -0800</pubDate>
    </item>
    </channel>
</rss>

