What's the threading like?

[GenSpoo]

Just curious how data is threaded. For example, say we have a function that does this:

tsbar1 = esignal.GetTimeSalesBar(handle, 0);
tsbar2 = esignal.GetTimeSalesBar(handle, 0);

Is it possible that tsbar1 and tsbar2 contain different data? If the esignal app receives a bar inbetween the two calls, what happens? I have to imagine that the esignal app is running its data collection thread separately from our ActiveX app, can't imagine it otherwise really. So how do we know this problem can't occur?

I guess the real issue is how data still coming in after calls to GetNumTimeSalesRtBars and GetNumTimeSalesBars and calls to GetTimeSalesBar is handled, but I'm just using the above example to illustrate. I can envision "skipping" over some bars on a very fast mover like ES.

Maybe I'm being paranoid, but I am still curious.

[mattgundersen]

Genspoo,

I believe eSignal is in a different thread space. This is being done with a COM/STL interface in eSignal.

That being said, I **think** what you say could happen but don't know for sure as I haven't seen it happen.

m.

[GenSpoo]

Ok. Then I would like to suggest that there be an absolute index system that would be valid once all historical ticks and/or bars have been loaded. Once a tickbar (or historybar) has been placed in a position in the array, there should an index for that bar that is unique and never changes. If I ask for bar at index 10 for one hundred times in a row, I should always get the same bar. So if I do something like:

lastIndex = esignal.GetLastTimeSalesIndex(handle);
for x = 0 to lastIndex
tsbar = esignal.GetTimeSalesBarAbs(handle, x);
endfor

I get what I want and I don't have to worry about the potential for bars to be sliding around as data is added to the array. In the above, data added after lastIndex will defintely get processed on the next loop without the risk of ticks slipping through.

[danharp]

I'm a bit confused by this as well.

It appears that the bars in the array are indexed by a negative value, relative to the latest bar?

IE, bar 0 is the latest, bar -1 is the previous, etc...

The OnTimeSalesChanged event is called whenever an update occurs, and you are maintaining an internal list of all the bars.

We are then supposed to determine the bars that have been updated since the last time the event fired (which should have been the last tick) and then use that value.

There are some problems that can occur with this setup.

For example, if you have 10 values when you start, and while working on number -5 another comes in, the following will happen:

The original number -4 value is now pushed to -5 and will be skipped.
You will continue processing the remaining 5 data points.
On the next run in the event, if there are 10 new data points, you will think there are 11.
You will then start reading from -11 since your counter is off, causing a duplicate tick. (it will be tick 0 from the last run)

Why not just implement it as a simple queue, and allow us to remove the data from the queue into our own storage location. We can then just empty the queue each time the event is called. Of course, there are issues with concurrency, as noted before, but it would be much simpler for us to determine what is left to be processed. As long as there is something in the queue, process it. When empty. you're done.

I think the problem lies in that you are maintaining your own internal list of the ticks and notifying us of the update. I would prefer to get the update itself in a queue. In the current implementation, I need to determine the number of ticks received, maintain a static or global variable to hold the last count, and get each of the individual ticks from the list. It would be much more efficient to just get each update until the queue is empty. If new updates come in while I am working, there will just be more on the queue.

The one advantage your method does present, however, is that it helps to eliminate stale ticks. If I can't process the data fast enough, ticks are dropped and I am getting current data. This is good in a real-time quoting system, but not if I am trying to collect tick data. Of course, you still have the issue of the duplicate tick.

I can also see needing to request historical ticks at the end of the day to ensure that I captured all ticks.

I am also confused by the example that includes the number of historical ticks...

GetNumTimeSalesBars(tsHandle)

Are historical ticks mixed in with the real-time ticks in this data? How do you determine which are which?

[mattgundersen]

Are historical ticks mixed in with the real-time ticks in this data? How do you determine which are which?

When ticks are requested, there are historical and realtime ticks.

They are not intermixed though. There is a clean seam between the two. (HT=Historical Tick, RT=Realtime Tick)

HT,HT,HT,HT,RT,RT

You would never see

HT,HT,RT,HT,RT

[JayF]

.

Originally posted by GenSpoo
Ok. Then I would like to suggest that there be an absolute index system that would be valid once all historical ticks and/or bars have been loaded. Once a tickbar (or historybar) has been placed in a position in the array, there should an index for that bar that is unique and never changes. If I ask for bar at index 10 for one hundred times in a row, I should always get the same bar. So if I do something like:

lastIndex = esignal.GetLastTimeSalesIndex(handle);
for x = 0 to lastIndex
tsbar = esignal.GetTimeSalesBarAbs(handle, x);
endfor

I get what I want and I don't have to worry about the potential for bars to be sliding around as data is added to the array. In the above, data added after lastIndex will defintely get processed on the next loop without the risk of ticks slipping through.

GenSpoo,

Thanks for the suggestion. Certainly, there is value to an absolute indexing system. I have passed this along in hopes in can be added to a future release.

[GenSpoo]

Thanks Jay. This would make me a very happy person.

[GenSpoo]

Originally posted by JayF
Thanks for the suggestion. Certainly, there is value to an absolute indexing system. I have passed this along in hopes in can be added to a future release.

Any ETA on absolute indexing? Are there any changes planned for the ActiveX control for the 7.5 release?