| Re: [mosquitto-dev] Time-related bug (of sorts) on Develop branch |
"Gellman, Rebecca" <rgellman@xxxxxxxxxxxxxxxxx> writes:
> In the db__new_msg_id() function, a message id is generated using the
> system clock (realtime, at nanosecond resolution) to generate an id
> that is reasonably unique. The problem begins with the seconds value
> (thus the current unixtime) have MOSQ_UUID_EPOCH subtracted from
> it. This is #defined to have a unixtime value that corresponds to
> November 17th 2021.
If the id only needs to be locally unique, I wonder if it would be
better to just start at 1 and count, sort of like a sequence field in a
real database. While unix systems ought to have the right time, it
seems best to remove as many requirements for that as possible.
> while ( id <= db.last_db_id ){
> id++;
> }
>
> This loop goes through about 17 quadrillion iterations trying to
> increment id from around 15,000,000 to 17,000,000,000,000,000. On a
> 500MHz single-core embedded processor, this takes a long time. In
> fact, it looks a lot like a lock-up.
>
> I've made a temporary change in our local build system to replace the loop above with the following:
>
> if ( id <= db.last_db_id )
> {
> id = db.last_db_id + 1;
> }
>
> This has the same effect, but executes in considerably fewer
> instruction cycles. Single Mosquitto runs in a single-thread there are
> no concurrency issues around db.last_db_id. I suspect the real problem
> is the subtraction of MOSQ_UUID_EPOCH, but without knowing the
> consequences of making more drastic changes I wasn't willing to poke
> that bear.
Your change looks good to me, independently of whether further changes
are warranted.
(I have only run mosquitto on systems with functioning real time clocks.
I have one client that is a RPI w/o RTC running NetBSD that sounds
similar to your embedded board, and multiple ESP8266/nodemcu sensors
that never have any idea of time.)
Attachment:
signature.asc
Description: PGP signature