From: Robert Pluim <rpluim@gmail.com>
To: Robin Tarsiger <rtt@dasyatidae.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: ai_flags in calls to getaddrinfo, broader call for reproducibility check
Date: Mon, 11 Jan 2021 19:42:02 +0100 [thread overview]
Message-ID: <8735z748p1.fsf@gmail.com> (raw)
In-Reply-To: <5cb6a0ac-9fe9-bfc2-5642-3423bd043238@dasyatidae.com> (Robin Tarsiger's message of "Mon, 11 Jan 2021 12:30:22 -0600")
[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]
Robin Tarsiger <rtt@dasyatidae.com> writes:
> Robert Pluim wrote:
>>> There is no _reliable_ way I know of to determine this programmatically,
>>> certainly not without sending some probe queries with a high level of
>>> specific control over them, and I expect that would be a rather hairy
>>> thing to do just for a few tests, and not reasonably maintainable.
>>
>> (require 'dns)
>> (skip-unless (dns-query "google.com" 'AAAA))
>
> Oh, wow, there's _already_ a dns.el in core? Huh. Well, that obviates
> my primary concerns about doing direct DNS probes, provided it works
> and is a reasonable thing to load for the test suite otherwise...
>
>> and then do the network-lookup-address-info tests (although on Windows
>> this depends on DNS over TCP working,
>
> Ergh. I just checked with `dig +tcp` against my crappy ISP CPE and it
> rejects the connection, which seems like anecdata toward that failing
> in a lot of configurations.
>
Yep.
> Do you happen to know OTTOYH _why_ datagram sockets aren't supported
> in Emacs on Windows to start with... ?
>
Because the select implementation on windows does a one-byte readahead
to see if data is available, which breaks UDP. I had a patch at one
point to fix this, but I remember Eli not being very enthusiastic
about it. Iʼve attached what I think is the right version below (my
windows box died, so I can't be sure)
>> and either /etc/resolv.conf or a
>> working nslookup).
> The latter should at least be stock on Windows AFAIK. I'd forgotten that
> it shows the list of resolver addresses too.
Itʼs my least preferred option, it depends on running an external
binary and parsing the output, which is fragile.
Robert
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sys_select_improvement.patch --]
[-- Type: text/x-diff, Size: 1745 bytes --]
diff --git i/src/w32.c w/src/w32.c
index 698e10e234..d14abc2f8e 100644
--- i/src/w32.c
+++ w/src/w32.c
@@ -8798,6 +8798,37 @@ _sys_wait_accept (int fd)
return cp->status;
}
+int
+_sys_wait_readable (int fd)
+{
+ HANDLE hEv;
+ child_process * cp;
+ int rc;
+
+ if (fd < 0 || fd >= MAXDESC)
+ return STATUS_READ_ERROR;
+
+ cp = fd_info[fd].cp;
+
+ if (cp == NULL || cp->fd != fd || cp->status != STATUS_READ_READY)
+ return STATUS_READ_ERROR;
+
+ cp->status = STATUS_READ_FAILED;
+
+ hEv = pfn_WSACreateEvent ();
+ rc = pfn_WSAEventSelect (SOCK_HANDLE (fd), hEv, FD_READ);
+ if (rc != SOCKET_ERROR)
+ {
+ rc = WaitForSingleObject (hEv, INFINITE);
+ pfn_WSAEventSelect (SOCK_HANDLE (fd), NULL, 0);
+ if (rc == WAIT_OBJECT_0)
+ cp->status = STATUS_READ_SUCCEEDED;
+ }
+ pfn_WSACloseEvent (hEv);
+
+ return cp->status;
+}
+
int
_sys_wait_connect (int fd)
{
diff --git i/src/w32.h w/src/w32.h
index cf1dadf64c..4a6b7c4b53 100644
--- i/src/w32.h
+++ w/src/w32.h
@@ -175,6 +175,7 @@ #define FILE_SERIAL 0x0800
extern int _sys_read_ahead (int fd);
extern int _sys_wait_accept (int fd);
+extern int _sys_wait_readable (int fd);
extern int _sys_wait_connect (int fd);
extern HMODULE w32_delayed_load (Lisp_Object);
diff --git i/src/w32proc.c w/src/w32proc.c
index de33726905..1e109669f7 100644
--- i/src/w32proc.c
+++ w/src/w32proc.c
@@ -1225,7 +1225,7 @@ reader_thread (void *arg)
else if (cp->fd >= 0 && (fd_info[cp->fd].flags & FILE_LISTEN) != 0)
rc = _sys_wait_accept (cp->fd);
else
- rc = _sys_read_ahead (cp->fd);
+ rc = _sys_wait_readable (cp->fd);
/* Don't bother waiting for the event if we already have been
told to exit by delete_child. */
next prev parent reply other threads:[~2021-01-11 18:42 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-31 15:06 ai_flags in calls to getaddrinfo Eli Zaretskii
2020-12-31 22:40 ` Robin Tarsiger
2021-01-01 7:43 ` Eli Zaretskii
2021-01-01 11:40 ` Robin Tarsiger
2021-01-01 12:04 ` Robin Tarsiger
2021-01-01 12:48 ` Eli Zaretskii
2021-01-02 0:19 ` Robin Tarsiger
2021-01-03 16:00 ` Eli Zaretskii
2021-01-11 10:47 ` ai_flags in calls to getaddrinfo, broader call for reproducibility check Robin Tarsiger
2021-01-11 12:42 ` Robert Pluim
2021-01-11 15:25 ` Eli Zaretskii
2021-01-11 15:47 ` Robert Pluim
2021-01-11 16:44 ` Eli Zaretskii
2021-01-11 17:07 ` Robin Tarsiger
2021-01-11 17:53 ` Robert Pluim
2021-01-11 18:30 ` Robin Tarsiger
2021-01-11 18:42 ` Robert Pluim [this message]
2021-01-11 19:28 ` Stefan Monnier
2021-01-11 20:12 ` Robert Pluim
2021-01-11 20:41 ` Eli Zaretskii
2021-01-11 20:55 ` Stefan Monnier
2021-01-11 21:02 ` Robert Pluim
2021-01-11 21:09 ` Lars Ingebrigtsen
2021-01-11 21:15 ` Robert Pluim
2021-01-11 22:42 ` Lars Ingebrigtsen
2021-01-12 9:40 ` Robert Pluim
2021-01-12 12:49 ` Lars Ingebrigtsen
2021-01-12 13:04 ` Robert Pluim
2021-01-12 14:08 ` Lars Ingebrigtsen
2021-01-12 14:29 ` Robert Pluim
2021-01-12 18:06 ` Lars Ingebrigtsen
2021-01-12 15:14 ` Stefan Monnier
2021-01-12 15:45 ` Eli Zaretskii
2021-01-12 3:29 ` Eli Zaretskii
2021-01-11 20:46 ` Eli Zaretskii
2021-01-11 20:56 ` Robert Pluim
2021-01-12 15:01 ` Eli Zaretskii
2021-01-12 15:36 ` Robert Pluim
2021-01-12 15:42 ` Eli Zaretskii
2021-01-12 16:00 ` Robert Pluim
2021-01-12 16:05 ` Eli Zaretskii
2021-01-12 17:56 ` Robert Pluim
2021-01-11 19:32 ` Basil L. Contovounesios
2021-01-11 20:19 ` Robert Pluim
2021-01-11 23:57 ` Andy Moreton
2021-01-12 9:44 ` Robert Pluim
2021-01-12 11:56 ` tomas
2021-01-01 10:59 ` ai_flags in calls to getaddrinfo Lars Ingebrigtsen
2021-01-01 12:50 ` Eli Zaretskii
2021-01-02 5:40 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735z748p1.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rtt@dasyatidae.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).