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
slguan
Jeff Tao
fangpanpan
lihui
hjxilinx
localvar
Jeff Tao
Li Cao
siddontang
Hongze Cheng