[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Asynchronous DNS
From: |
Alain Schneble |
Subject: |
Re: Asynchronous DNS |
Date: |
Sun, 7 Feb 2016 18:45:53 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) |
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?
- Re: Asynchronous DNS, (continued)
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/09
- Re: Asynchronous DNS, Andreas Schwab, 2016/02/08
- Re: Asynchronous DNS, Alain Schneble, 2016/02/08
- Re: Asynchronous DNS, Andreas Schwab, 2016/02/08
- Re: Asynchronous DNS, Alain Schneble, 2016/02/08
- Re: Asynchronous DNS, Andreas Schwab, 2016/02/08
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/08
- Re: Asynchronous DNS, Alain Schneble, 2016/02/09
- Re: Asynchronous DNS, Alain Schneble, 2016/02/09
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/07
- Re: Asynchronous DNS,
Alain Schneble <=
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/07
- Re: Asynchronous DNS, John Wiegley, 2016/02/08
- Re: Asynchronous DNS, Rasmus, 2016/02/08
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/08
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/08
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/06
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/07
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/07
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/08
- Re: Asynchronous DNS, John Wiegley, 2016/02/07