10

To be clear, I'm not talking about anything that should require emacs to be multithreaded (though that would probably also solve this). To reproduce:

  1. emacs -Q # I'm running 24.4.1
  2. Make a second frame
  3. Switch back to first frame
  4. M-x shell
  5. M-x rename-uniquely (we're going to make a second shell later)
  6. Start running: while true; do echo "hello world"; done
  7. In the second frame, M-x shell

The second shell will almost never display (rarely it works after repeated attempts). Apparently emacs will never take a break from reading the output of the first shell to listen to the output coming in from any other process. It would be much better behavior for it to round robin when there are multiple processes with pending output. Is there any way to get better behavior?

The only trick I know would be to make the shell buffer its own process, but unfortunately that won't work for me. Even if I do that, I have to run a subprocess to listen to a socket for my speech recognition software to work so that I can actually control the shell in the first place, that's how I discovered this; running an infinite loop like the above prevents any data from being taken off the socket.

Joseph Garvin
  • 2,061
  • 8
  • 21
  • 1
    I don't have a specific answer to your question. However, I like to use `start-process` with a `set-process-filter` and a `set-process-sentinel` -- this lets me go on my merry way doing other stuff while the process runs -- I even send my output sometimes to the `*Messages*` buffer using `insert` so that my echo area is untouched, or I use a dedicated process output buffer (if needed). For example, I can run a lengthy `rsync` session. I don't have any experience trying to run multiple simultaneous / lengthy `start-process`, so I'm not sure how Emacs would handle a slew of them all going on. – lawlist Feb 03 '15 at 02:15
  • 2
    Hmm interesting find. Both shell inferiors are separate processes and obviously Emacs is still processing its main command loop without issue. However I suspect when it polls the inferior FDs it always finds something on the first shell and never gets to processing the second FD. If you kill the while [1] in the first shell the second shell does indeed come up as you expect. This is probably a question for the dev mailing list. – stsquad Feb 03 '15 at 11:16
  • I have another problem but it's smiliair with frames: http://lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html – ReneFroger Nov 10 '15 at 13:38

1 Answers1

2

So this isn't a proper solution but I ran your test the other way around (e.g. the while [1] on the second shell) and it works fine. As a work around you could ensure that any shell buffers that are likely to be generating heavy output are created later than the ones where you want interactivity. That way the interactive shells are the first to be handled by Emacs' inferior poll before finally handling the one that generates lots of output.

In practice if you are running a selection of interactive shell you will likely not be in a situation where one hogs the I/O for so long. If you regularly need such a thing maybe redirecting the output into a file and using view mode is a better solution?

stsquad
  • 4,626
  • 28
  • 45
  • 1
    The issue here is it's not hard to write an infinite loop by accident. I'd also prefer to not have to think about how much I/O I plan to do when running commands. The whole advantage of using emacs is that everything is already in a nice save-able buffer :) – Joseph Garvin Feb 04 '15 at 16:10
  • 1
    @JosephGarvin I appreciate that. I think the best solution if to M-x report-bug with your excellent reproducer. – stsquad Feb 04 '15 at 16:23