Lars Ingebrigtsen <larsi@gnus.org> writes:

> The issue is losing asynchronicity.  A function that previously called
>
> (progn
>   (make-network-stream ... :nowait t)
>   (set-process-coding-system ...))
>
> would not block.  With the proposed blockers (unless we add fine-grained
> code to all the process function to only block if we haven't even done
> DNS yet), this code will block.  And that's a regression.

By the way, I tried it out with the fine-grained approach.  See patch
below.  The majority of the functions touched will block if DNS requests
are still pending.  process-send-* functions block while process is in
"connect" state.  I didn't have time to verify it with TLS connections
though, and also just very quickly with http connections and some hand
crafted scenarios...

> But, I mean, we could examine all these process functions and only have
> them block where we need them to, and things would work fine.  I don't
> really have much confidence in us being able to do so completely
> transparently, though.

There is potential to refactor at least two functions,
set-process-coding-system and set-process-window-size, to not require
blocking at all.  The former will require adaptions in
set_network_socket_coding_system, to check whether coding systems have
already been set, so that they do not get overwritten, e.g. in this
scenario:

(progn
  (make-network-stream ... :nowait t)
  (set-process-coding-system ...))

And set-process-coding-system could just jump over the call to
setup_process_coding_systems in case of a network process with pending
DNS requests (i.e. socket not yet available).

While with set-process-window-size, I asked myself if this one makes any
sense with network processes at all.  Should it signal an error or what
would be the use case to call this for a network process?

And here is the small patch I used: