In order to maintain internal API integrity, each of engine.SubmitOrder(), engine.CloseOrders() and engine.MergeOrders() called outside the main strategy thread (onBar, onTick,etc) are best handled via the context.executeTask() mechanism allowing the strategy thread to coordinate requests to these methods from 3rd party threads - everything ordered, everything managed.

But what about this IOrder.close().

A. If I have IOrder firstOrder, and call engine.CloseOrders(firstOrder) outside the strategy thread that requires executeTask.

B. So doesn't firstOrder.close() require this too given that the call (while in a 3rd party thread) causes interaction with the same internal logic used to effect the mass order case in A.?

Or perhaps IOrder.close() is already written to consider the thread it is called in and to effect contingencies internally (i.e. where the current thread isn't the strategy one -> queue up a close request internally for the strategy thread to process, or utilise context.executeTask() internally, or something similar).

Or perhaps my understanding of the internals is wrong.

Please offer some insight at your convenience on this aspect as the engine.SubmitOrder(), engine.CloseOrders() and engine.MergeOrders() scenarios make sense yet I'm nervous about the naked IOrder.close() calls I have occurring within concurrent threads.

Many thanks.

All order-changing operations have to be called either from the strategy thread or the method IContext.executeTask.