Tag Info

Hot answers tagged

14

It's certainly not new, it's just where the industry (not just MS) has been making a lot of progress lately in terms of making it more accessible to sub-geniuses. Historically doing async programming was more cumbersome and difficult, consider the async socket api in windows for example. With the new tools & abstractions coming out, it gets easier ...


14

The only difference between the two is the synchronization used in StringBuffer. The overhead of synchronization is not huge in the grand scheme of things, but it is significant relative to the StringBuilder methods that don't have them. The JVM is doing work that it wouldn't otherwise have to do--especially with only one thread, etc. If your code works ...


13

When Node.js is described as "non-blocking", that specifically means that its IO is non-blocking. Node uses libuv to handle its IO in a platform-agnostic way. On Windows, it uses IO completion ports, on Unix, it uses epoll/kqueue/select/etc. So, it makes a non-blocking IO request (which may have a background thread monitoring, but this is never exposed to ...


12

I think you're getting a few things confused, here. What you're asking for is already possible using System.Threading.Tasks, the async and await in C# 5 are just going to provide a little nicer syntactic sugar for the same feature. Let's use a Winforms example - drop a button and a textbox on the form and use this code: private void button1_Click(object ...


12

Unfortunately, the answer is, "it depends." It would be easy for you to write a small program to empirically determine the times of both async and sync reads. It will depend on lots of factors. Are they stored on spinning disks, SSD, or a network drive? What kind of CPU are you using? How many sockets/cores? Are you running in an VM or bare metal? Are ...


11

So, something's been bugging me about the new async support in C# 5: The user presses a button which starts an async operation. The call returns immediately and the message pump starts running again - that's the whole point. So the user can press the button again - causing re-entrancy. What if this is a problem? Let's start by noting that this is ...


8

You will be able to accomplish your task using BackgroundWorker. It is a well known class, and many people have used it. The new C# 5 async and await keywords basically just make it easier to write readable asynchronous code. There may be fewer tutorials and examples of how to accomplish various tasks with these keywords rather than BackgroundWorker. ...


7

I've used RequireJS on serious projects, and I love it, but it's not really meant to be an asynchronous loader. It's really meant to be a module system. Asynchronous loading is provided in service to that goal. It can be pushed to fill any of your requirements, but its loading services are designed to load modules, not arbitrary files. Load JavaScript and ...


7

Async has 3 main advantages: It lowers CPU utilization. This could be useful if you are also doing CPU-heavy operations with data you just read. Using some kind of async infrastructure makes the code easy to paralelise. Especially if you are reading lots of files. By sending multiple read-write requests to OS, OS and HW can re-order those operations to be ...


7

In general, any function that does networking or uses timers to do things over a period of time will be asynchronous. If the function takes a callback, you can look at what the callback is used for and usually it will be obvious whether is is asynchronous or not. If the function does not offer a callback, then it has no way of communicating asynchronous ...


6

is it OK to use blocking libs in non-blocking environment No. A non-blocking server works because everything is non blocking. The moment you use any blocking code you create a huge bottle neck. Non blocking servers use a single process/thread and an event loop. The moment you block inside the process your blocking the entire HTTP server. This will ...


6

All of your logic is sound, except that I think your understanding of functional programming is a bit too extreme. In the real world functional programming, just like object-oriented, or imperative programming is about mindset and how you approach the problem. You can still write programs in the spirit of functional programming while modifying application ...


6

"Goodbye JS"... Really? C# is a server-side language. The appearance of async in C# is not going to affect client-side languages and frameworks like Javascript at all (except that calls Javascript makes to the server will return faster). "Does this new era call for a new generation of web frameworks?" The beauty of async is that you can use it anywhere ...


6

You will probably find this MSDN article about Asynchronous practices to be a good read. You asked: Unfortunately while DatabaseFolderRepository implementation used synchronous methods to talk with database, skydrive one uses a lot of async and await. This is where the sub-section Async All the Way in the MSDN article I linked will be pertinent to ...


5

Why do you think disabling the button before the await and then re-enabling it when the call completes is fragile? Is it because you are worried that the button will never get re-enabled? Well, if the call doesn't return then you can't make the call again, so it seems that this is the behaviour you want. This indicates an error state that you should be ...


5

The async and await keywords will not make your application more responsive on their own. They simply make the calling and handling of methods that return Task objects more convenient. In order to make async/await actually use background threads, you will need to combine with the usage of things like: Task.Start() - Starts a given task using the ...


4

I don't know about "best practice". I do know the most common mistakes. First Mistake: DOS Yourself You use the webhandler to process the long running job. This can be bad or extremely bad depending on your percentage of hits that become long running jobs, how long they run and how much sustained traffic you get. You want to make sure that you aren't ...


4

This is a fascinating question. The most interesting take on it is, in my view, the approach adopted in Clojure and explained in this video: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey Basically the "solution" proposed is as follows: You write most of your code as classic "pure" functions with immutable data structures and no side ...


4

I'm not sure if this applies to you since I usually use WPF, but I see you referencing a ViewModel so it might. Instead of disabling the button, set an IsLoading flag to true. Then any UI element you want to disable can be bound to the flag. The end result is that it becomes the UI's job to sort out it's own enabled state, not your Business Logic. In ...


4

Yes, for the UI thread, the callback of a await operation will happen on the original thread of the caller. Eric Lippert wrote an 8-part series all about it a year ago: Fabulous Adventures In Coding EDIT: and here's Anders' //build/ presentation: channel9 BTW, did you notice that if you turn "//build/" upside down, you get "/plinq//" ;-)


4

In short, yes. Synchronous HTTP requests halt execution of subsequent code while they are en route. While browsers may no longer block the UI during this time, we're relying on the user's available bandwidth, network reliability, and the server's current load for the performance of our code. This is generally not good practice. On the MDN "Using ...


4

As for patterns the "Enterprise Integration Patterns" book could be worth while. As for technologies I think a service bus, like NServiceBus or MassTransit, might help you.


4

It's highly unlikely that you can achieve with plain js the same level of conciseness and expressiveness in working with callbacks that C# 5 has. The compiler does the work in writing all that boilerplate for you, and until the js runtimes will do that, you will still have to pass an occasional callback here and there. However, you may not always want to ...


4

It's never absolutely necessary for a controller to be async. Calls to controller methods will eventually return. However, it might be desirable to hand off a long-running task to a thread, so that the web server is not blocked for a long period of time. I wouldn't bother making every controller asynchronous. There is some overhead involved in creating ...


4

You want a semaphore. def input(): make_network_call() sem.acquire() return shared_return_value def callback(): shared_return_value = whatever sem.release() This makes input() block on the acquire() line until release() is called in the callback. The caller to input() isn't aware a callback was involved. Make sure to initialize the ...


3

In the demos I've seen, they disable the button before the await call and enable it again afterwards. This seems to me like a very fragile solution in a real-world app. There is nothing fragile about this, and it is what the user would expect. If the user needs to wait before hitting the button again then make them wait. I can see how certain ...


3

You're planning to deal with much concurrent activity, so that means you've got to think in terms of atomic operations. That means using transactions. Now, you don't want to hold a transaction for a long time as it blocks other transactions, so you have to think about using the transactions to protect minimal state changes and putting guards on the UPDATE ...


3

You could in theory just keep a list of scripts already loaded, and make a function that loads scripts that haven't yet been loaded. http://jsfiddle.net/BDG/Dhdu7/2/


3

It depends One thing to keep in mind is how expensive is a context switch between processes. Node.JS is designed the way it is because it assumes that doing a context switch is very expensive and you will otherwise have a lot of processes waiting on IE which will bog down the computer. On the other hand Erlang makes a process context switch very cheap so ...



Only top voted, non community-wiki answers of a minimum length are eligible