fix & enhancement for udp connection handling
1. potential data race in `taosProcessMonitorTimer`: the issue does not exist at present because there's only one scheduler thread, which means there's no cocurrent calls to this function for a same `pMonitor`. but if more scheduler threads are created later, there's a data race issue in rare case. as threads number can be easily increased by increase the value of `taosTmrThreads`, it is very unlikely that the developer could realize this function need to be revised together. that's why i say it is a 'potential' issue. this issue happens in below scenario: a. scheduler thread1: `if (pSet)` is true and new timer is installed by `taosTmrReset`; b. scheduler thread1: `if (pMonitor->pSet == NULL)` is true but `taosTmrStopA` is blocked, either by the mutex of the timer or os thread scheduler. c. timer thread: 200ms elapse, new call to `taosProcessMonitorTimer` is initialized in scheduler thread2; d. scheduler thread2: `if (pMonitor->pTimer != tmrId)` is false; e. scheduler thread1: unblocked, stops timer and frees `pMonitor`; f. scheduler thread2: unexpected behavior because `pMonitor` is not valid any more. because the result of this issue is crash or worse, i suggest to fix it though the possibility of all the conditions are met is very very low. 2. `pthread_attr_t` related issues: per manual, an initialized `pthread_attr_t` can be reused, should be destroyed, and the behavior of re-init it is undefined. this issue exist in other modules also. 3. memory leaks; 4. improve failure case handling of `taosInitUdpConnection`; 5. typo
Showing
想要评论请 注册 或 登录