Re: Asynchronous DNS

[Alain Schneble]

Eli Zaretskii <address@hidden> writes:

> That's not my reading of the code.  Perhaps I'm missing something.
> Could you tell the details -- where do you see this?

The probability that I'm missing something is infinitely larger ;)  And
at the same time I'm infinitely thankful to you and Lars for taking the
time to read my messages so thoroughly.

> What I see is this: process-send-string calls send_process, which
> signals an error if either the status of the process object is other
> than 'run' or its output file descriptor is invalid.  But
> make-network-process takes care to arrange for both of these: it calls
> make_process, which sets the process status to 'run' and sets up its
> output file descriptor to a valid value (the socket we got from the
> call to 'socket').

Up to this point, I fully agree.

>                      It does that even if the connection is
> asynchronous and has not yet completed.  So I don't expect an error in
> this scenario with the existing code.

Well, there's this code a few lines after p->outfd has been set, in
connect_network_socket:

  if (p->is_non_blocking_client)
    {
      /* We may get here if connect did succeed immediately.  However,
         in that case, we still need to signal this like a non-blocking
         connection.  */
      pset_status (p, Qconnect);
      if (!FD_ISSET (inch, &connect_wait_mask))
        {
          FD_SET (inch, &connect_wait_mask);
          FD_SET (inch, &write_mask);
          num_pending_connects++;
        }
    }
  else

To me this reads like the process status is set to Qconnect until the
asynchronous connection is fully set up.  Near the end of
wait_reading_process_output, the status is set to Qrun again just before
invoking the sentinel function:

  pset_status (p, Qrun);
  ...
  exec_sentinel (proc, build_string ("open\n"));

> If the connection is asynchronous, and is not yet completed, then
> send_process will wait in a loop, because the write to the socket will
> return EWOULDBLOCK or EAGAIN.

This I see, but only if the above mentioned Qconnect state wouldn't be
there.

> Did I miss something?

Am I misinterpreting it?