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

[J.P.]

Mattias Engdegård <mattiase@acm.org> writes:

> Although it seems reasonable to require that filter functions abstain
> from sending more data to the process,

I think "app makers" (those of us building on Emacs as a platform) need
a solid, authoritative pattern to mimic. What we at ERC are trying with
our test server is to invert this "reactor pattern" by limiting the role
of the filter to that of "reconstitutor of application frames." When one
or more complete protocol frames arrives (in our case, CRLF delimited),
it enqueues them and returns, perhaps after stashing any residual bytes
for the next invocation. [1]

Then, concurrently, we have our main handler/dispatcher loop, which is
started by a specific sentinel event. It peeks at the queue and then
maybe dispatches a method/reply handler or maybe handles housekeeping
instead. The key for app makers, I think, is that we regain control by
being free to deal with complete messages (remote "method calls" or
"return values," logically) at a time and place of our choosing, rather
than being forced to the dance to the tune of the selector.

> there may be another way: preventing re-entering process-send calls
> from recursing further.
>
> 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.)

> Of course, one reason to make the change in ERC is that it would fix the
> problem in all Emacs versions, not just 29.

You mean make the change by abstaining from the antipattern, right? I
think ERC has no choice but to do just that because we're an ELPA
package supporting multiple versions of Emacs.

[1] https://git.neverwas.me/repos/erc-v3/tree/test/erc-d/erc-d.el?id=f1af52#n442