the basic idea is to change clean up procedure to 2 steps,
the 1st step only marks the time controller as to be cleaned up,
the 2nd step executes in the timer thread and does the
actual job to avoid race.
I also change `pCtrl->ticks = rand() / pCtrl->maxTicks` to
`pCtrl->ticks = rand() % pCtrl->maxTicks`, because I think
this is a typo but not sure about this.
1. fix memory leak:
`memset(&pool_p, 0, sizeof(pool_p))` sets the pointer to NULL,
so `free(pool_p)` does nothing.
2. improve performance by move some code to the outside of the lock.
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
1. check all memory allocation failure in `taosInitScheduler`;
2. make `pSched->numOfThreads` the actual number of created threads
to avoid crash in `taosCleanUpScheduler` when `pSched->qthread` is NULL
and other issues;
3. check interruption of `sem_wait` in `taosScheduleTask`,
and use `pTrace` instead of `pError` when `sem_wait` was interrupted;
4. cancel all threads before join them to enable cocurrent cancellation;
5. remove unused global variable.
Field names and values are both returned. Client application gets value by field name. It runs as convention except that bool type is returned as one byte,tiny integer. Bool type will be returned in future if tiny integer causes confusion.
slguan
huili
localvar
Hongze Cheng
fang
plum-lihui
liuliang
Zimeng Pan
robot