On 23 January 2016 at 21:50, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:


> I see four ways of implementing an async name resolution function:
>
> 1) Add a new `resolve-name' function that would fork Emacs, call
> getaddrinfo/gethostbyname, and do a callback once we get a reply.  The
> problem is that a forked Emacs is a very strange thing, and is not
> something we otherwise do.  I looked at this for a day last time, and I
> couldn't get it to work, really.  Perhaps somebody else could, though.
>
> 2) Use one of the newer async C resolver libraries.  This would not be
> available on all platforms, and would be Yet Another Dependency which
> I'm sure everybody would rather that we avoid.
>
> 3) Create a tiny helper program in lib-src that would read names from
> stdin and output resolves on stdout.  It would use
> getaddrinfo/gethostbyname, and could very well be multithreaded, so that
> it could do name resolution on parallel.
>
> 4) Pick the data out of res_init to find the DNS servers, and then just
> use dns.el for name resolution.  This would be trivial to implement, but
> may not respect the name resolutions settings on some operating systems.
>

This is something I have been wondering for a while, and I think that this
may be
as good a time as any to ask the question.

Are there any technical reasons why the name resolution (or whatever it is
that
needs to be asynchronous) could not be run in a thread in the Emacs process
itself? As long as the thread is not running any Lisp code, it should work,
correct?

I'm asking this because I've had some ideas on modules that I would write
once
the loadable module support in Emacs is complete, and in some cases I want
to be able to do stuff in threads.

Regards,
Elias