Re: Asynchronous DNS

[Alain Schneble]

Lars Ingebrigtsen <address@hidden> writes:

> Eli Zaretskii <address@hidden> writes:
>
>> If we introduce such a thread, its code needs to be carefully audited
>> for the above-mentioned gotchas.  E.g., passing to it a C pointer to a
>> contents of a Lisp string is probably unsafe.  It's not rocket science
>> to DTRT in this case (we already do that quite a lot on MS-Windows),
>> it just requires very careful programming and code review.
>
> Sure.  But I think that for the getaddrinfo_a thing, it really is that
> simple.  Everything is allocated and freed in the main thread, the
> address lookup doesn't need to access anything Lispy, etc.  (This is how
> the structure of the getaddrinfo_a library already works.)
>

Just for the record, getaddrinfo_a creates at least one detached worker
thread to synchronously call getaddrinfo.  If all threads are busy, it
will spawn new threads.  Idle workers will die eventually after some
period of inactivity.

So far so good.

>Alain Schneble <address@hidden> writes:
>
>But still, I wonder why there is no call to `gai_cancel' at all.

What I meant with this is that, when working with external resources,
the caller should explicitly account for the "unusual" (e.g. shutdown)
cases as well, explicitly, IMHO.  Given the case where any number of
async DNS requests are still pending and the (OS) process is to be
terminated, it should explicitly cancel all pending requests before its
last heartbeat.  For me, this sounds like best practice.  I understand
that it works properly without it in this async-DNS-feature case.  But
still -- maybe due to my zero knowledge about glibc -- I see the DNS
resolve library as a black box.  It could well have started let's say a
new OS process which does the resolve and which would survive our
"initiator" OS process if the requests are not explicitly cancelled
before termination.  One could argue that this would then be a bug, but
maybe not. I'm happy to learn that such things won't ever happen in
glibc by convention.

Furthermore, in your proposal, processes with pending DNS requests are
maintained in a separate list `dns_processes'.  If a LISP process gets
deleted by a call to `delete-process', and DNS requests are still
pending for it, it might be that `connect_network_socket' will be called
even though the process has been deleted.  Shouldn't
`deactivate_process' cancel any pending requests for that process?  Or
do we just forget about this probably "theoretical" case?

Alain