c# - Run an async function in another thread -

i'm evaluating async ctp.

how can begin execution of async function on thread pool's thread?

static async task test() {     // something, await }  static void main( string[] args ) {     // there more elegant way write line below?     var t = taskex.run( () => test().wait() );      // doing more in same thread     t.wait(); // waiting more single task, example } 

i'm new (my virginal post) stack overflow, i'm jazzed you're asking async ctp since i'm on team working on @ microsoft :)

i think understand you're aiming for, , there's couple of things you're doing correctly, there.

what think want:

static async task test() {     // something, await }  static void main(string[] args) {     // in ctp, use task.runex(...) run async method or async lambda     // on .net thread pool     var t = taskex.runex(test);     // above shorthand     var t = taskex.runex(new func<task>(test));     // because c# auto-wraps methods delegates you.      // doing more in same thread     t.wait(); // waiting more single task, example } 

---

task.run vs. task.runex

because ctp installs on top of .net 4.0, didn't want patch actual system.threading.tasks.task type in mscorlib. instead, playground apis named fooex when conflicted.

why did name of them run(...) , of runex(...)? reason because of redesigns in method overloading hadn't completed yet time released ctp. in our current working codebase, we've had tweak c# method overloading rules right thing happens async lambdas - can return void, task, or task<t>.

the issue when async method or lambdas return task or task<t>, don't have outer task type in return expression, because task generated automatically part of method or lambda's invocation. seems right experience code clarity, though make things quite different before, since typically expression of return statements directly convertible return type of method or lambda.

so thus, both async void lambdas , async task lambdas support return; without arguments. hence need clarification in method overload resolution decide 1 pick. reason why have both run(...) , runex(...) make sure have higher quality support other parts of async ctp, time pdc 2010 hit.

---

how think async methods/lambdas

i'm not sure if point of confusion, thought i'd mention - when writing async method or async lambda, can take on characteristics of whoever invoking it. predicated on 2 things:

• the type on awaiting
• and possibly synchronization context (depending on above)

the ctp design await , our current internal design both pattern-based api providers can flesh out vibrant set of things can 'await' on. can vary based on type on you're awaiting, , common type task.

task's await implementation reasonable, , defers current thread's synchronizationcontext decide how defer work. in case you're in winforms or wpf message loop, deferred execution come on same message loop (as if used begininvoke() "rest of method"). if await task , you're on .net threadpool, "rest of method" resume on 1 of threadpool threads (but not same 1 exactly), since pooled begin , you're happy go first available pool thread.

---

caution using wait() methods

in sample used: var t = taskex.run( () => test().wait() );

what is:

1. in surrounding thread synchronously call taskex.run(...) execute lambda on thread pool.
2. a thread pool thread designated lambda, , invokes async method.
3. the async method test() invoked lambda. because lambda executing on thread pool, continuations inside test() can run on thread in thread pool.
4. the lambda doesn't vacate thread's stack because had no awaits in it. tpl's behavior in case depends on if test() finished before wait() call. however, in case, there's real possibility blocking thread pool thread while waits test() finish executing on different thread.

that's primary benefit of 'await' operator allows add code executes later - without blocking original thread. in thread pool case, can achieve better thread utilization.

let me know if have other questions async ctp vb or c#, i'd love hear them :)