C# Console application causes eSignal crash

[TritonSystems]

I am writing a C# console application to retrieve symbol quotes. In the OnQuoteChanged method I am trying to access the eSignal object to call GetBasicQuote. However, eSignal crashes as soon as the program starts up.

I was wondering if anyone else ran into this problem at any point in their development? My assumption is that this is a threading issue, i.e. I am trying to access the esignal object from a different thread than the object was intantiated on?

[Guest]

eSignal should not crash like that. I think you are right on with the threading hypothesis. Does the problem go away if you run in a single thread?

[JimBecker17]

You need to access the ActiveX object using the same thread which created it.

If you printout the exception thrown error message it gives you text that sez this in some curt manner.

You can have the ActiveX thread be grabbing all the data then have your other thread coordinate with it once the data is in your desired format.

-Jim

[kanstey]

Threading with eSignal

I had also designed a mult-threaded application to receive eSignal events.

What I found during debugging was that the callback from the eSignal component (i.e. OnQuoteChanged event) is actually fired on various threads allocated from the .NET thread pool.

Thus, you actually don't really need to create your own alternate thread in order to receive the data as the event callback will occur on thread pool threads, whose lifetime will be managed by .NET.

My application is a simple WinForm application that shows a counter when quotes are received and processes them. It could just as easily be a console application.

If you debug your app, and watch the list of threads in the debugging window, you should see the behaviour I am describing.

I just thought that this might be of some use to you.

[Dierk Droth]

Hi,

Just my 2 cents:

1) kanstey is correct: the events throws by eSignal are on differents threads than the thread where the eSignal object was initially created.
2) The docs hold various samples calling eSignal methods/properties in an event handler without re-directing the call to the original thread.
3) Thus, it should be perfectly safe to access the eSignal object from multiple threads.

Robi, could you please confirm or make corrections if necessary?

Regards

[sthornington]

Threads

eSignal is a single-threaded application, for the most part. The COM apartment should also be single threaded, causing all requests to be serialized through eSignal's main thread.

The .NET interop library you have may not be correctly marshalling to the single-threaded apartment, if you can post a project that demonstrates this, I can take a look at it and see what the marshaller has created.

Cheers,

Simon.

[Dierk Droth]

Simon,

Thanks for providing this information.

Please take a look at the project I posted today here: http://forum.esignalcentral.com/show...6&pagenumber=1 (muell.zip).

On placing breakpoints at the OnBarsRecieved and OnBarsChanged event handler you will notice that these events come in on different threads than the one where the eSignal object was created.

Regards

[sthornington]

I've seen that behaviour now, and also confirmed that eSignal is sending the events from it's main thread, so this must be known behaviour of the CLR/.NET interop layer. I can't immediately find any documentation of this however.

[Dierk Droth]

Simon,

Thanks for checking and confirming.

So the question remains: Is it safe to call eSignal methods/properties from different threads in .NET or should all calls be redirected to the same thread (which initially created the eSignal object) ?

Regards

[JimBecker17]

Dierk,

My development world is VC++ 6.0, which doesn't allow this.

In this world the message associated with the thrown exception said it was used from the wrong thread. If .NET lets you do this then it should work w/o the exception.

So if it's not safe should fail right off, not down the road a bit.

All my stuff works off the main thread now, except T&S which is in a totally different application.

-Jim

[sthornington]

As I said, this is a matter that the marshaller takes care of, if you are running an STA, you may get better performance than if you are running an MTA, but the choice is yours.

The COM/interop system will ensure that calls to eSignal are serialized.

[kanstey]

Based on what I know of Interop, this is the behaviour of events from a COM object via the .NET interop layer.

As Simon alluded to earlier, the interop layer should ensure that your requests to the eSignal object are marshalled to the correct STA (i.e. the one in which the object was initially created)

I have had no problems with my application in this regard.

As you all probably know, however, beware of any sort of GUI updates from any thread but the one which created the GUI objects. Use Invoke for ensuring that GUI operations occur in the main application thread.

If you are updating the GUI from another thread, this can lead to as Microsoft (in their standard non-commital way) states : "Undesirable behaviour", which in my experience, is latin for "blows up real good!!!"

Hope this may help


-Kevin