杰杰

> 1、platform_thread_init函数中，xTaskCreate的最后一个参数应该是&thread->thread，而不是V1.1.0版本中的thread->thread。 > platform_thread_init函数的自测代码修改为： > > ``` > err = xTaskCreate(entry, name, stack_size, param, priority, &thread->thread); > ``` > > 2、platform_thread_destroy函数中，先将任务删除，然后再释放内存的逻辑无法顺利运行。当任务删除后，无法运行到vTaskDelete的后一条释放语句。 > platform_thread_destroy函数的自测代码修改为： > > ``` > TaskHandle_t threadToBeDeleted; >...

> 经过仔细思考，我最终修改了mqtt_ack_list_scan函数，添加了删除msg handler的代码。 > > 在Suback、unsuback等命令超时的情况下，会删除对应的msg handler，避免heap区的空间越来越少的bug。不知道 @jiejieTop 您如何看？修改的思路可对？ > > ``` > /* if it is not a qos1 or qos2 message, it will be destroyed in every processing...

> /* release all ack_handler_list memory */ > if (!(mqtt_list_is_empty(&c->mqtt_ack_handler_list))) { > LIST_FOR_EACH_SAFE(curr, next, &c->mqtt_ack_handler_list) { > ack_handler = LIST_ENTRY(curr, ack_handlers_t, list); > mqtt_list_del(&ack_handler->list); > if(NULL != ack_handler->handler) //@lchnu, 2020-10-08,...

> 机缘巧合下,看见了有微信推文说这个工程特别厉害,设计思路特别优秀.本着想要学习与提升的目的阅读了这个项目. > 在阅读了作者的README与代码后,想向作者确认一个细节问题. > 关于 mqtt_yield_thread 这个线程里的 mqtt_yield 函数,其工作方式是一直以cmd_timeout为时间单位来检测是否有各种类型的报文要处理是吗? > 即, 即使没有报文要处理,还是会计时检测. 是的，因为内部线程一直会在运行的，当没有数据传输的时候，依旧还是需要保持活性的（keep-alive），否则服务器会认为你是断开了，当然啦，内部已经实现保活机制了的，你不用担心。只是线程会阻塞cmd_timeout时间单位，然后看看是否需要keep-alive，然后再次进入休眠状态。

> 想请教一个问题，在异步publish的时候，里面有buffer机制嚒？ > 就是说，调用者只管异步publish数据到buffer（线程安全的），而库自己去维护这个buffer，当网络ok的时候，自动把数据发送到服务器 是线程安全的，在多线程publish操作buff的时候，是通过互斥锁保护的，这些是mqttclient内部的处理，无需用户去关注哈。

> 今天又来逛了一圈，我去，又完善了这么多，自动生成代码都有了，666啊。 哈哈哈哈，玩起来嘛~

> 大佬，有windows平台的代码么？ 暂时没有哦~

> 膜拜大佬！！！ > 刚熟悉这个库，关于收发 `buf` 大小有点疑问，向您请教。 > > 1. 创建客户端时在 `mqtt_init` 中动态申请了读写缓存的大小，按照 `mqtt_defconfig.h` 中的配置，默认值为 1024 。后续设置读写 `buf` 大小只是改变了结构体变量值，并没有重新刷新 `buf` 的大小，这个是否该重新刷新更合适？ > 2. 实际应用场景下，如需要接收 `64K` 的报文，这种情况下改了 `MQTT_DEFAULT_BUF_SIZE` 也不能够成功，您有处理过这种场景么？ 已解决哈,感谢提出~当时看到了,忘了回复了

目前未适配Windows，您这边可以自己写一个platform

可以的,回头我用原始函数声明一下!