bug#69241: Fixed patch issues

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniel Pettersson <daniel@dpettersson.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  69241@debbugs.gnu.org
> Date: Mon, 11 Mar 2024 10:44:38 +0100
> 
> João Távora <joaotavora@gmail.com> writes:
> 
> > The calls must be processed in the order of the queue though, but in
> > theory that shouldn't lead to O(N^2) if a suitable technique is found (perhaps
> > different from (run-at-time 0)).
> 
> The first patch I sent had this issue of them being process out of
> order.  But the second patch ensures that they are handled correctly.
> It may look like they don't but they do :)
> 
> 1. We push each message on 'jsonrpc-mqueue (Order is reversed)
> 2. We pop each item of 'jsonrpc-mqueue and push (Guaranteed by sharing
> the same `time' for each timer) the item on `timer-list'.
> 3. Timers are evaluated in the order of `timer-list'.

Can't the code activate the timers in reverse order?  Then each
timer--activate will likely compare with just one timer, the first
one.

> This is not that straight forward and loops back to my point of relying
> on timer.el internals, but as I see it there is no other way, if one
> would like to get around the internal sorting of timers in timer.el
> which I would very much like to do.

Timers must fire in the order of their time, so they must be kept
sorted, or else running the timer functions and removing the timer
from the list will be much more complex.

Assuming that timers are sorted is not relying on the internals, if
you ask me.

> (why does an "medium" sized modern js web project require 5000 sources
> is the real question we need to ask ourselves)

Indeed.  Any idea of what the answer could be?