[emacs-berlin] Code review for a simple HTTP async client

Michael Heerdegen michael_heerdegen at web.de
Thu Jan 4 00:34:11 UTC 2024

jman <emacs-berlin at city17.xyz> writes:

> Due to the single-threaded nature of Emacs, handling async tasks is
> unwieldy. Opting for a sync HTTP client is equally not great because the
> entire UI would block until the operation completes. And since this
> involves a remote server, the waiting is undefined (could even timeout
> at 30 seconds).
> The only way I could make it work reliably was to remove the global
> variable and put the Location URL from the header into the kill ring.

This doesn't sound appropriate.  If you think the kill-ring (which is,
at the end, just the value of a global variable) is more appropriate
than a global variable, you are doing something wrong.

Depending on what exactly you want to implement, the approach to use is
callbacks and process filters.  There are a lot of things in Emacs that
silently wait for process output without blocking Emacs (e.g. *shell*
buffers, `man' page rendering, `find-dired' buffer filling).  In these
cases, only the external processes are and need to be asynchronous -
Emacs doesn't have to run anything asynchronously itself.

If you don't want to let Emacs wait, putting the relevant parts of the
control flow of your code into callbacks and process filters will solve
your problem.  This stuff will run automatically when the process status
has changed and Emacs is idle ("accepts process output").

In cases where you really _want_ to wait until some process has done
something particular , you can use a simple loop that calls `sit-for'
with small amounts of time as argument until what you expect has
happened or some timeout limit has been reached.  This is useful only
rarely, however (if you know for sure the user wants to wait for the
result and it won't take long, for example).


More information about the emacs-berlin mailing list