On 2024/9/18 23:05, Stephen Hemminger wrote:
> On Wed, 18 Sep 2024 15:37:49 +0800
> fengchengwen <fengcheng...@huawei.com> wrote:
>
>> ...
>>
>>> +
>>> +static enum {
>>> + LOG_TIMESTAMP_NONE = 0,
>>> + LOG_TIMESTAMP_TIME, /* time since start */
>>> + LOG_TIMESTAMP_DELTA, /* time since last message */
>>> + LOG_TIMESTAMP_RELTIME, /* relative time since last message */
>>> + LOG_TIMESTAMP_CTIME, /* Unix standard time format */
>>> + LOG_TIMESTAMP_ISO, /* ISO8601 time format */
>>
>> Some of the impl should consider multiple-thread safety.
>>
>> And for multiple-process, how about the secondary-processes align the
>> main-process.
>
>
> As much as possible, they are thread safe, that is why locatime_r is used.
> Of course if multiple threads are printing it is possible that time stamps
> could be out of order. I.e CPU A got timestamp and is formatting message,
> and CPU B got timestamp is formatting message. The formatting might take
> longer for A.
Yes, the localtime_r is thread safe, but like delta, multi thread will both
read and update
global variable log_time.previous with any sync, this may lead problem.
static struct {
struct timespec started; /* when log was initialized */
struct timespec previous; /* when last msg was printed */
} log_time;
e.g.
1, the previous tv_sec = 1000, tv_nsec = 90000;
2, thread A invoke log, and current tv_sec = 2000, tv_nsec = 10000; it will
update the previous
3, thread B also invoke log, and current tv_sec = 2000, tv_nsec = 10001, but it
read previous is tv_sec = 2000, tv_nsec = 90000
and the delta will invalid.
