AsyncOperation not working as I expected

  • Thread starter Thread starter Lee Alexander
  • Start date Start date
L

Lee Alexander

Hi,

I'm trying to use AsyncOperation to execute a method in a main thread
context from a worker thread. If I run the program from a console
application then it doesn't work. If however I run it from a WindowsForms
application it does. Basically I set the name of the main thread to "Main
Thread", when the "ShouldBeInMainThreadCall" is called the
Thread.CurrentThread.Name is null. However if I run it in a WindowsForms
application it has the correct name. Could anyone help me with this?

Find below the source for the console app:

using System;
using System.Threading;
using System.ComponentModel;

namespace TestThreadAffinityEvents
{
class Program
{
private static AsyncOperation operation;
private static void DoWork()
{
operation.Post( new SendOrPostCallback( delegate( object state )
{
ShouldBeInMainThreadCall();
} ), null );

operation.OperationCompleted();
}

static void Main( string[] args )
{
Thread.CurrentThread.Name = "Main thread";

Thread workerThread = new Thread( new ThreadStart( DoWork ) );
operation = AsyncOperationManager.CreateOperation( null );
workerThread.Start();

int i = 0;
while( true )
{
Console.WriteLine( string.Format( "Hello from {0} {1}",
Thread.CurrentThread.Name, i++ ) );
Thread.Sleep( 500 );
}
}

static void ShouldBeInMainThreadCall()
{
Console.WriteLine( string.Format( "Calling you from {0}",
Thread.CurrentThread.Name ) );
}
}
}


Cheers
Lee
 
I'm trying to use AsyncOperation to execute a method in a main thread
context from a worker thread. If I run the program from a console
application then it doesn't work. If however I run it from a WindowsForms
application it does. Basically I set the name of the main thread to "Main
Thread", when the "ShouldBeInMainThreadCall" is called the
Thread.CurrentThread.Name is null. However if I run it in a WindowsForms
application it has the correct name. Could anyone help me with this?
Click to expand...

Console applications don't (normally, at least) run a message pump or
anything similar - the main thread just runs until it's finished all
its work. There's no way of getting back to the "main" thread of a
console application (without extra work to basically have your own
producer/consumer queue).

Jon
 
Hi Jon,



Yeah I figured that was the case, the thing I find perplexing is the
difference in behaviour, in that when run under Windows Forms the delegate
gets run in the main thread SynchronizationContext whereas under the console
application it runs in a seperate thread. It seems to be a recipe for
problems if a component that relies on this is run within both Console and
Windows Forms (message pump) scenarios.



Maybe I'll add a little comment on the Community Content mentioning this..



Cheers

Lee
 
Lee Alexander said:
Yeah I figured that was the case, the thing I find perplexing is the
difference in behaviour, in that when run under Windows Forms the delegate
gets run in the main thread SynchronizationContext whereas under the console
application it runs in a seperate thread. It seems to be a recipe for
problems if a component that relies on this is run within both Console and
Windows Forms (message pump) scenarios.

Maybe I'll add a little comment on the Community Content mentioning this..
Click to expand...

Well, it's doing the most appropriate thing for the context in which
it's running. The idea is that if you've got an appropriate context,
you can get the framework to use it (although I don't know the details)
- but console apps just don't have that synchronization context.
 
Back
Top