[PATCH v23 11/15] log: add timestamp option

[fengchengwen]

On 2024/9/18 23:05, Stephen Hemminger wrote:
> On Wed, 18 Sep 2024 15:37:49 +0800
> fengchengwen <fengchengwen at 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.