3 ms·

I'm not up to date what GNU Emacs does with by default concurrent threads of Lisp code on multiple cores. What is the story there? I would think that each Zmac

by lispm 4y ago

I'm not up to date what GNU Emacs does with by default concurrent threads of Lisp code on multiple cores. What is the story there? I would think that each Zmacs instance from 40 years ago already ran in its own thread.

taeric 4y ago
My impression has been that emacs itself does fine with multiple processes. As seen by the compilation buffer being fine. So, if you setup a sentinel and do the process buffer technique, things can be done. Most people lament the lack of threads, though. More, I think most people do not want to build the necessary stuff for a process buffer to help. Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.
- lispm 4y ago
  If I start a long running Emacs Lisp function in IELM (the GNU Emacs repl), then GNU Emacs is completely unresponsive. My Lisp Machine emulator for Symbolics Genera is still responsive for the same code snippet, entered in a Listener window.
  - taeric 4y ago
    Right. I know if you don't do the process buffer code, you can freeze things. And I can fully cede that doing that for elisp is weird. Same idea in a sly buffer, though, is fine. Edit: For amusement, I was trying to see how bad it could be, so I made a loop to get the 90000th fib. Which, wasn't enough to see here. Hard to really appreciate how fast computers have become.
    - lispm 4y ago
      sly is easier, there the computation is done by a remote Common Lisp. But the danger may be long running output operations, unless they explicitly give up control for other (possibly green) threads. But in a Lisp application to not be responsive at all is kind of rare. Most Lisp application runtimes will be able to process interrupts and/or switch "green threads" or "native threads".

by lispm 4y ago

taeric 4y ago

My impression has been that emacs itself does fine with multiple processes. As seen by the compilation buffer being fine. So, if you setup a sentinel and do the process buffer technique, things can be done. Most people lament the lack of threads, though. More, I think most people do not want to build the necessary stuff for a process buffer to help. Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.

lispm 4y ago
If I start a long running Emacs Lisp function in IELM (the GNU Emacs repl), then GNU Emacs is completely unresponsive. My Lisp Machine emulator for Symbolics Genera is still responsive for the same code snippet, entered in a Listener window.
- taeric 4y ago
  Right. I know if you don't do the process buffer code, you can freeze things. And I can fully cede that doing that for elisp is weird. Same idea in a sly buffer, though, is fine. Edit: For amusement, I was trying to see how bad it could be, so I made a loop to get the 90000th fib. Which, wasn't enough to see here. Hard to really appreciate how fast computers have become.
  - lispm 4y ago
    sly is easier, there the computation is done by a remote Common Lisp. But the danger may be long running output operations, unless they explicitly give up control for other (possibly green) threads. But in a Lisp application to not be responsive at all is kind of rare. Most Lisp application runtimes will be able to process interrupts and/or switch "green threads" or "native threads".