bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack overflow

[J.P.]

"J.P." <jp@neverwas.me> writes:

> Mattias Engdegård <mattiase@acm.org> writes:
>
>> Attached is a proof of concept: if process-send calls are invoked when
>> another activation already exists, just enqueue the data and let the
>> previous activation deal with the actual transmission. That nips the
>> recursion in the buds.
>
> This seems an ingenious way of helping problematic code that already
> exists. I'll give it a whirl just for fun. (But alas, I know nothing.)

FWIW, I ran ERC's I/O heavy test suite (not yet part of Emacs) against
these changes, and it passed. I also tried them out on that quasi-repro
recipe (the one with the python script), and the problem vanished
transparently, as expected.

BTW (cc. Fernando), the reason I simply dropped nested send attempts in
that earlier patch was because their payloads (those 4-byte receipts)
are only meaningful to a sender honoring "the spec" [1], which says

  The sender should not continue to transmit until the recipient has
  acknowledged all data already transmitted.

IOW, there shouldn't be prohibitive wire pressure when dealing with an
obedient sender, so we needn't worry about an outgoing receipt being
dropped (right?). And for corner-cutting senders, either those just
treating receipts as heartbeats and ignoring their contents or those
never bothering to read from the socket at all, "sparse but strictly
increasing" should always suffice, I think. If I'm wrong on either
count, we can always add more complexity.

QUICK ADMINISTRATIVE NOTE: this whole time, I've been neglecting to Cc
the emacs-erc mailing list (a lapse in professionalism on my part). So
for anyone replying up thread, please cc. emacs-erc@gnu.org, if you
happen to remember. Thanks.

[1] https://www.irchelp.org/protocol/ctcpspec.html