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.

Improve this question
3
  • 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 3, 2015 at 2: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 3, 2015 at 11:16
  • I have another problem but it's smiliair with frames: lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html
    – ReneFroger
    Nov 10, 2015 at 13:38

1 Answer 1

Reset to default
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?

Improve this answer
2
  • 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 4, 2015 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 4, 2015 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.