开云体育

h future individually, also there is a lot more liquidity, than buying/selling the spread outright.

Well, weight in the fact that I am not a fan of Excel for handling fast pace data. (and here you deal with 'ticks' which is rated 2nd fastest data set of the API) Maybe other members have better experience.
Typically what seems an easy start may end up pretty painful, spending precious hours tweaking and 'workarounding' Excel limitations that will eventually fail to your expectations.

IMHO and without understanding if your purpose is to get an Excel spreasheet to look at, or to use Excel to compute and takje decision. Anyway you better organize "rendez-vous" in your code and get ride of "loop".
In short: you need a multi-thread method. yours seems single threaded. C# have good provision for it.

Assuming you never stop the 4th loop. Look to me that you need a 5th 'loop' (a thread in real), this is probably the most important for you within your current architecture, and it must be in a separate thread, this one only handle saving data.
Using SQL could be a simple solution as this will allow you to save faster (maybe) and more important collecting data from a central repository that by itself have all provision to handle concurrency of data access. This would preserve most of your existing code.

However depending upon how serious is your project you should use more of an appropriate language like Java or C# (in full) or C++ , it's not so hard to get some fundamental and it pay.
The API allows you to start any request you mention asynchronously and ASAP, Scanner answers are pretty slow, can be done at this moment. Be careful with contractdetails you may hit many pacing limitations.
IB have a pretty efficient and fast API, you can't keep up using Excel as the orchestrator.

Seems you use C#, keep the effort, if you don't know how to do multi-threading, start learning how to launch a thread, then either connect to a MySQL or learn how to share data between thread using a mutex, then ... many many details but later.

That sounds like a standard answer from a tier 1 support person. I would consider the counterpoints..

It's true there's a global interpreter lock, which may be in Python 3. It's also true that async code is single threaded, but in this circumstance you still need to be careful where you await. Finally, neither you nor IB mentioned anything about how many different instances of this program you may be running... if it's more than one you could certainly have a problem.

So again, since you haven't provided a picture of the whole system, there's no great point in speculation.

Of course testing is worthwhile, but static code analysis and formal verification are different beasts altogether. And, this is why I simply said "You might have problems but I won't conjecture on their likelihood."

I know my reply was somewhat esoteric. Therefore, to make up for that a tiny bit, I'd suggest that you use the "+= 1" idiom instead of adding constants to your order ID. In addition, you'll want to learn about different methods of doing an atomic increment in Python as well as how to leverage critical sections. You should be able to significantly "future proof" your code when and if necessary with those two things.

Still, these are all Python related (and concurrent programming) issues in general which the API can't address for you. Although I greatly enjoy the subject, it's a bit off-topic for this email group.

I contacted IB, they told me the following:

Concurrency assumes that two task may overlap each other in execution. In python GIL(Global Interpreter Lock) prevents multiple threads from accessing the same python object. Only one thread can hold the GIL at a time and one thread must wait for another thread to release the GIL before running.

If i understand everything right - your code will run one thread that will asynchronously place bracket orders.In this case this task is still single-threaded but asynchronous and you should not encounter any issues with order id's if they are incremented during the execution of run_loop().

So anyway, I tested my code yesterday on paper like 20 times and it seems to work fine, I checked there were no order id clashes.

I also made another version where there was a second queue inside the function for the orders themselves, meaning if 2 api calls for price came back at the same time, the orders will be queued up, but it works exactly the same as the first version I described. Will try it again on paper today.

On Sun, Aug 20, 2023 at 10:26 AM, omgwtfsalty@... wrote:

I am worried that I will place to orders at the exact same time and the order id's will get messed up.

You might have problems but I won't conjecture on their likelihood. They may not be exactly as you've described either, but there's no way to know much more from just a snippet of code. Details of the rest of the system need to be provided and considered... e.g. is this running in wsgi?

On Sun, Aug 20, 2023 at 10:26 AM, omgwtfsalty@... wrote:

Is there a way around this

Yes... of course. Potential solutions, however, have much more to do with Python and concurrent programming in general than they do with the IBKR API.

Check out my profile and follow the link to MIT's 6.031 class if you want to learn more about those topics. There's also a video by David Beasley in my profile... it's really great! But before you check those out, I suggest you sit through the 1986 videos of SICP and work through the book at the same time.... it's a masterpiece IMHO.

On Sun, Aug 20, 2023 at 10:26 AM, omgwtfsalty@... wrote:

does twsapi automatically mitigate this

Not really, this kind of thing is the responsibility of the end user. With a little work I'm sure you'll be able to come with something. Good luck!

I am not familiar enough with Python but a couple of things maybe be generic

1- you have a side 'thread' that deliver you a condition that look like a HTTP return code, right ?
aiohttp.ClientSession() which will use same credentials, hence same session as your own main thread.
2- your own thread will place a bracket order (and look like you understood the purpose of 'transmit')
Your concern is that your order id will be messed up, but with what ?

Your code should better take some precaution as you seems to me to mix 2 different technologies, the SDK and the REST.
You better call self.reqIds(-1) at least once yourself and track the call back of nextValidId before you use app.nextOrderId().?
Read the sequence (init+operation+report) in
and consider the 2 call back openOrder and orderStatus. you SHOULD listen to it.
Start keeping thing simple, there is no harm to call self.reqIds(-1) and it is fast