I think having a single-threaded async/await style interface for doing non-blocking things like creating and reading output from subprocesses could be pretty nice.
As far as I can tell Emacs already supports the primitives required to implement an async/await style interface. The way it works now, is that the editor is one big event loop. The event loop handles reading keyboard input and eval'ing the elisp functions bound to those keys, and while that's not happening, non-blocking things like subprocesses are being progressed. This happens outside of elisp, inside of the C part of Emacs somewhere.
Right now subprocesses support using custom "sentinels", these are an elisp function that gets called by the event loop whenever the subprocess progresses in some way.
I'm not really a concurrency expert but I think you could work these already existing things into a nice interface. Having built in support for this would be a huge upgrade!
There are libraries like emacs-aio that try to do this, but I don't know very much about them right now, but that should at the least serve as a proof of concept.
As far as I can tell Emacs already supports the primitives required to implement an async/await style interface. The way it works now, is that the editor is one big event loop. The event loop handles reading keyboard input and eval'ing the elisp functions bound to those keys, and while that's not happening, non-blocking things like subprocesses are being progressed. This happens outside of elisp, inside of the C part of Emacs somewhere.
Right now subprocesses support using custom "sentinels", these are an elisp function that gets called by the event loop whenever the subprocess progresses in some way.
I'm not really a concurrency expert but I think you could work these already existing things into a nice interface. Having built in support for this would be a huge upgrade!
There are libraries like emacs-aio that try to do this, but I don't know very much about them right now, but that should at the least serve as a proof of concept.