Closed rahilarious closed 1 year ago
I don't expect to fix the throughput issue any time soon due to the design of Circe. It uses one network process with a sentinel processing incoming input. If it's busy with
/list
output, it is bound to reply late to any incomingPING
.
Can this be changed? The issue also affects other situations e.g. when other modes are doing something and block the ui.
There are very specific workarounds, such as using several processes and waiting for either of them to be ready for processing. That's a crutch for Emacs being ultimately single-threaded and packages expecting this kind of design.
So no, there is no generic solution, short of a complete Emacs/Circe redesign. Such a redesign would need to test what exactly is slow here (is it slow to merely run the process filter several times? is it slow to display the output repeatedly? could the output be collected and paged through in that case? how would that even work with asynchronous code? would that require the use of promises?) and target these pain points specifically.
Just use
/quote list
if you want to actually use the command. Note that it's a bad idea to do this because the output of the command can be massive and Circe will be so busy processing it all that it may not reply to the keepalive ping commands and ends up disconnecting from the network as a result.For this reason, networks affected by this issue recommend either:
/list
with modifiers to limit the output. Try/quote help list
for further info on network-specific modifiers, such as/quote list *pattern*
/msg alis help list
and/msg alis list pattern
.I don't expect to fix the throughput issue any time soon due to the design of Circe. It uses one network process with a sentinel processing incoming input. If it's busy with
/list
output, it is bound to reply late to any incomingPING
.What I could do is introduce a dummy command pointing out the above gotchas or even change the output for unknown commands to suggest trying the
/quote
command. What do you think?