bug#69241: Fixed patch issues

[Daniel Pettersson]

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'.

Simplified:
(setf timer-list (append (reverse (reverse messages)) timer-list))

:)

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.

> Finally 50.000 is a gigantic amount -- are all of these essential?  Can't the
> server coalesce this data into fewer messages within the DAP protocol?

Sorry I made an error it's 5000, this is js-debug sending an list of
javascript sources for "medium" sized js React project and no that cant
be configured.  Which as I stated in my other reply leads to 12,500,000
(N^2/2) calls to `timer--time-less-p' (timer sorting in timer.el) but
with my patch only requires 5000.

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

/Daniel