[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ai_protocol
From: |
Ken Brown |
Subject: |
ai_protocol |
Date: |
Mon, 23 May 2016 10:01:26 -0400 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 |
I'm puzzled by the handling of ai_protocol in process.c, starting with
the following commit:
commit e09c0972c350e9411683b509414fc598cbf387d3
Author: Lars Ingebrigtsen <address@hidden>
Date: Thu Jan 28 23:50:47 2016 +0100
Refactor make_network_process
* src/process.c (set_network_socket_coding_system)
(connect_network_socket): Refactor out of
make_network_process to allow calling connect_network_socket
asynchronously.
(Fmake_network_process): Do nothing but parsing the parameters
and name resolution, leaving the connection to
connect_network_socket.
Before that commit, the calls to 'socket' in Fmake_network_connection
looked like this, in a loop through the structures returned by getaddrinfo:
for (lres = res; lres; lres = lres->ai_next)
{
[...]
s = socket (lres->ai_family, lres->ai_socktype | SOCK_CLOEXEC,
lres->ai_protocol);
After that commit, there is a loop in Fmake_network_connection that
builds a list 'ip_addresses', as follows:
for (lres = res; lres; lres = lres->ai_next)
{
ip_addresses = Fcons (conv_sockaddr_to_lisp
(lres->ai_addr, lres->ai_addrlen),
ip_addresses);
ai_protocol = lres->ai_protocol;
Notice that the variable ai_protocol is reset on each iteration of the
loop. Later we have
p->ai_protocol = ai_protocol;
so that the process's ai_protocol is set to whatever value was assigned
on the last iteration of the loop.
Then connect_network_socket is called. It loops through ip_addresses
and does
s = socket (family, p->socktype | SOCK_CLOEXEC, p->ai_protocol);
always using the fixed value p->ai_protocol as third argument. This
seems wrong, but maybe I'm missing something.
Ken
- ai_protocol,
Ken Brown <=