经过验证，貌似不是的锅。还是主贴中的join引起。

我将tdapi中的exit逐行打印注释，

int TdApi::exit()
{
    this->active = false;
    this->task_queue.terminate();
    std::cout<<"terminate ok\n";
    this->task_thread.join();
    std::cout<<"join ok\n";
    this->api->RegisterSpi(NULL);
    std::cout<<"RegisterSpi ok\n";
    this->api->Release();
    std::cout<<"Release ok\n";
    this->api = NULL;
    std::cout<<"NULL ok\n";
    return 1;
};

在多次长时间实测后会偶然复现无法退出的现象，日志打印如下：

2022-05-25 10:21:49.872169 id1_xxx执行登出操作开始。（gateway）
id1_xxx执行登出。（gateway）
terminate ok （pyd）
join ok （pyd）
RegisterSpi ok （pyd）
Release ok （pyd）
NULL ok （pyd）
id1_xxx 执行登出操作完毕。 （gateway）
2022-05-25 10:21:49.894205 id2_xxx 执行登出操作开始。 （gateway）
id2_xxx执行登出。（gateway）
terminate ok （pyd）

也就是说，id2退出时，this->task_thread.join();这句话未能执行完，卡在这了。

而由于退出操作是以事件形式执行，进而导致事件引擎卡在这个事件处理上，最终整个ui卡住。

搜索CTP相关资料时，找到这么一篇文章，https://blog.csdn.net/zhangzq86/article/details/49583993?utm_source=copy

其中提到：

三、CTP退出
调用Release函数即可，不需要delete的
这里要注意的是：在Release之前不需要调用RegisterSpi(NULL);注销Spi的，如果这样做了，有可能导致CTP退不出的。

而vnpy的ctp封装，正是先调用了RegisterSpi然后再Release释放的。

目前遇到的情况是：
多账号下，偶发的gateway.close()主动退出会导致卡死（退出是发出事件，注册的函数执行gateway.close()，通过打印发现，基本上是tdapi下的self.exit()后面的打印没能打印，怀疑是self.exit偶发故障）

怀疑是

int TdApi::exit()
{
    this->active = false;
    this->task_queue.terminate();
    this->task_thread.join();

    this->api->RegisterSpi(NULL);
    this->api->Release();
    this->api = NULL;
    return 1;
};

上述代码中的task_thread.join();会引起（动态链接库层面的异常导致）阻塞后无法退出的情况吗？

结合py310的数据共享，大有可为

图表这方面，先抛开功能是否满足需求，至少有个不能影响当下整个框架的运行效率，单开进程去显示图表是个大前提。基于这个前提下，图表功能越丰富越好。

优秀！hxx一直在增量的发布创造性内容。

这就完全是两个东西啊。
说个不恰当的比喻，vnpy相当于特斯拉，然后终于某厂的车也开始搞电动车了。。你想结合一下。
不是不行，是没必要。

没有权限获取分钟数据

你的要么试用、要么到期了

看起来大概能猜到一些。
是本身tick的属性增加之后，数据库里的基于psycopg2+bar/tick构造的自动保存的结构没有增加对应属性。
这块也是我升级的顾虑————这方面的顾虑是，tick我存到了不可变数据库中，无法修改。更别说字段修改了。除非全部导出，涉及好后再导入，工程量太大。

要明白这个tick.high_price，我们首先要阐述一下行情的推送机制：
期货行情1秒2个tick，也就是说接收数据是500ms的截面数据而非订单簿数据。

截面数据：500ms内撮合成交后的结果数据。
订单簿数据：500ms内撮合成交了多少笔交易，就应该推多少个tick。

由此，就可能产生一个现象：我们接收到的tick数据和上一个tick的时间段内可能已经撮合产生了截至tick推送时的当日最高/最低价，但500ms时间结束撮合的最后价格却不是最高/最低价，由此，导致了tick.last_price与tick.high_price/tick.low_price并不一致。

而tick.high_price/tick.low_price却是真实代表当前当日最高最低价的。

以上。

修改 .vntrader下的vt_setting.json即可。

Eden wrote:

首先出现问题

然后解决

只要CtpTdApi的类下的这个函数里面的这段不运行就没问题了
不过我又想了几个问题
1、这一段不运行对有界面Trader运行时有无影响
2、行情数据是不是要在Trader中订阅过才能在无界面时查询到合约数据？
3、如果策略的设置，本身在C:\Users\Eden.vntrader\cta_strategy_setting.json文件中已经有创建了，但是vt_symbol输错了，这样的话就会显示“行情订阅失败，找不到合约XXXX”。例如我情况json文件里的Class_name:model1,
vt_symbol:IF2016.CFFEX(20年哪有16月), strategy_name:model1，而无界面代码中的vt_symbol填的是IF2106.CFFEX，class_name和strategy_name均是model1，但还是出现了问题-----无界面代码中无法更新JSON文件里的vt_symbol。最终我只能手动在json文件里改了vt_symbol。那么如何在无界面中直接解决这个问题呢？而且如果无界面实盘交易时碰到合约换月，无法解决这个问题的话就有点难办了

别靠猜，要自己测试，
另外，猜测的大多都不对，影响很大。

飞哥不会飞 wrote:

xiaohe wrote:

可以打开.vntrader文件夹下的cta_strategy_data.json进行手动修改

好的谢谢
还有另外一个问题，如果是手动开了仓，然后修改了json数据后，那个持仓和策略能不能对应上

不能。需要看你策略的数量是多少。

重新编辑了，看来是解决了

1、付费使用米筐数据源，自带主力连续数据。交易时，你只需要对接上当前主力的价格即可。
2、自己合成
2.1、设计换月规则
2.2、根据换月规则合成主力，推送给策略使用。

具体合成方法，参见论坛内帖子。

这种个例的需求，你不去适应大多数，而让大多数适应你，不合适吧

这属于pandas科学计算的范畴了。

先df对齐。

indexs = list(set(df1.index.tolist() + df2.index.tolist()))
df1 = df1.reindex(indexs)
df2 = df2.reindex(indexs)

策略写的有问题。

xiaohe wrote:

self.trading是控制策略交易状态的；
底层资金获取论坛里有相关帖子；
实时输出状态的话，可以write_log

题主要的不是底层资金，要的是策略组合的权益（等同于理论回测值）

你这需要完整的设计方案，这种方案的实现，光方案就有价值，更别说实现了。
结果你结尾来了一句“即可”，仿佛不要太简单一样。