not top level in wrap-native for #<subr read-event> (root cause: dgram socket full causes read-event, but if the dgram is full before command-entry, the current-command can be root) about explain-pause-mode HOT 4 OPEN

@bqv, how did you find out about explain-pause-log-to-socket?! 😀 it's undocumented!

Did you happen to actually call explain-pause-log-to-socket with a real DGRAM UNIX file socket?

There is also a bug here that explain-pause-log--send-command-entry needs to be called after entering the command frame so that the read-event has a root, but... I don't think you kew about this feature, did you? In which case, I don't know how the dgram code fired...

But if you did know about this feature, you have to use a DGRAM socket accept that is fast enough to process all the DGRAM packets or else eventually the buffer will get full and then explain-pause-mode will give up on the socket - which is what it was trying to do.

from explain-pause-mode.

Whoops :D yes, I was digging around and set it to log to systemd's /dev/log. Clearly it can't keep up, that's a shame, I was liking that feature

from explain-pause-mode.

Oh, is it! Haha, well, well @bqv ! Yes, then that explains why this bug happened. I will do an audit and make sure any time packets are written we've entered a frame and then at least you'll just a message "Sorry the buffer is full, stopping logging" instead of crashing out.

As for some hints about what to log it to, you can change the size of the buffer with explain-pause-log--dgram-buffer-size, it's set to 256. But it can easily be much bigger; it's just a circular buffer implemented in a vector. So far, when I've been using it, I've found that when you're typing, it's usually pretty OK, but if you're accepting packets from HTTP etc, it can be a problem. You may want to try using socat and then using it to buffer the input and have it then send the output to systemd. Another option is to write a little program that can accept and buffer?

I really want to make it so that a separate emacs process can stream the socket input and then build a proper visualization in buffer and explain-pause-top, but I'm dreading it because I think emacs won't be able to accept input fast enough, so I was already thinking about either using a existing *nix utility (preferable) or building something in python/go/something-not-C to buffer.

Another option I'm thinking about is to switching to TCP sockets, but the emacs C code for TCP send will yield to other code, which is of course bad when you're trying to instrument everything-emacs-runs :D So, to do TCP I would implement a producer-consumer using the same circular buffer. That would help with accept and backpressure, but he tradeoff there unfortunately though would be that sometimes emacs could lock up or do GC and you wouldn't be guaranteed to stream the command entry before it starts, whereas right now, if the DGRAM socket is fast enough, we're sure to send the record.

I might make it an option.

But yes, the stream is actually super useful, and it's really scary/interesting how much stuff executes in emacs to just accept one key press sometimes :O

If you have ideas about how you'd use the feature, where you'd like to log to , if you would find TCP much more useful, etc. let me know your thoughts.

The original intent of the socket was to finally be able to "See what emacs is doing when it pauses!", which is why I originally chose the UDP DGRAM socket, but it's been a real pain so far...

from explain-pause-mode.

That all sounds worthwhile! I've personally attempting to use it to narrow down what might be causing a recurring crash, and it seems very useful theoretically to just have "more logs" in systemd, but you're right, it's probably a good idea to buffer it out with socat or similar.

Alternatively, if your solution demotes it to a warning which carries on logging after, I'm happy to have small silent spots at least for this purpose :)

Either way, definitely a neat feature

from explain-pause-mode.