1. the shell should not remove escape sequence \' and \" in a string.
2. `tsParseTime` should not unescape the next string token (this issue
appears after the first issue was fixed).
3. `value[4] != '-'` in `tsParseTime` crashes in rare case if `value[4]`
is in unallocated virtual memory.
4. `operator[x]` and `delimiter[x]` may result in unexcepted behavior
as string is utf-8 encoded and `x < 0` could be true.
5. changes the behavior of `tscGetToken` a little: now, unescaped single
quotation is allowed in double quoted strings and unescaped double quotation
is allowed in single quoted strings.
6. minor performance improvements and other improvements.
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
huili
Hongze Cheng
slguan
localvar
Jeff Tao
Jeff Tao
johnnyhou327
haojun Liao
黄科
fang