Re: Asynchronous DNS

[Alain Schneble]

Eli Zaretskii <address@hidden> writes:

>> `process-send-region', `process-send-string', `process-send-eof'
>> 
>> Maybe the last three wouldn't be candidates as they throw an error even
>> in the current implementation in case the process status is still
>> 'connect, as you and I pointed out already in earlier notes.
>
> But if the wait is for the 'run' status, then it will fix those
> problems as well (as I think we should).

FWIW, I think I more and more tend to like this approach, where all
those functions would block when called before the socket is connected
-- incl. process-send-* functions that currently signal an error.

Here is a quick (dump 'my 'humble 'mind) of what I think I learned from
all of you so far in this thread and the arguments that make me feel
more and more confident about this promising path:

- We would get a very robust API that will DT(R)T, regardless of whether
  an async expert or a non-expert writes code against in.  Both may fall
  into the blocking "trap".  But those that care will certainly notice
  it.  They will be the ones that read the documentation carefully,
  where it will cover this new async subtlety -- that functions
  accepting an async network process (made with :nowait t) and called
  before its state turned to "open" may block.
  
- It will fix the inconsistency between process-send-* function and the
  others (such as set-process-coding-system), where the former today may
  signal errors while the latter do not.  Having process-send-*
  functions block will certainly only fix issues and shall not introduce
  new ones.

- Current (Lisp) API won't change at all.  No need to extend :nowait.
  Current semantics of nil and t remain.  We do not introduce any new
  idioms or configurations (e.g. that would be the case with 'immediate)
  that we might regret in the future.  It should be fully backward
  compatible.

- As it does not introduce any new concepts, it leaves the path open for
  extensions, should it turn out that a strict async programming model
  might be preferable over "the lax one" described above.  We could
  still introduce things like this:

  (make-network-process ... :nowait 'strict-async
    :sentinel
    (lambda (p s) (
      (await p)
      ...
     )))

  ...where await /must/ be called in this 'strict-async mode.  If p is
  used in a function (e.g. process-send-*) without having awaited it,
  all these functions would signal an error.  So before any usage, one
  must await for p.  If p's state is "open", then it's a no-op.  If not,
  it would block until it is.

Did I miss something?

As said, besides the last point, this really is a summary of other's
(Eli, Lars, Andreas) ideas and remarks.  Thanks you, it's so interesting
:)