Re: Asynchronous DNS

[Eli Zaretskii]

> From: Lars Ingebrigtsen <address@hidden>
> Cc: address@hidden
> Date: Wed, 03 Feb 2016 11:42:57 +1100
> 
> > We need to know which code can run on a separate thread, because some
> > things cannot be safely done from any thread but the main
> > (a.k.a. "Lisp") thread.  Running the Lisp interpreter is one of them,
> > but it's not the only one.  You cannot QUIT or signal an error or do
> > anything else that throws to top-level.  You cannot call malloc or
> > free, or any code that does.  You cannot modify any data structures
> > visible from Lisp, like buffers, Lisp strings, and the undo list.  You
> > cannot access or modify global variables or call any non-reentrant
> > Emacs functions.  And there are other no-no's, these are just a few
> > that popped in my mind within the first 5 sec.
> 
> Except the malloc thing, that just boils down to "you can't do anything
> Lispy on the other threads" I think?

I don't think "anything Lispy" is a useful definition, since almost
everything we do in Emacs on the C level is "Lispy" in some way.  And
a C programmer won't see too many "Lispy" things, I think.  E.g., QUIT
just calls longjmp, a standard C function.  Many functions that have
potentially long loops call QUIT inside the loop, and you cannot call
those in a non-main thread.  Assigning values to a global variable is
standard C practice, but there are some (quite a few, actually)
variables in Emacs which cannot be safely assigned from a non-main
thread, unless you introduce some synchronization mechanism.

> Which nobody has proposed, anyway.

I was just explaining why knowing that we are starting application
threads, and knowing what code these threads can run, is important.

> > However, it sounds like this is all much ado about nothing: I see no
> > references to any threads, old or new, in the changes you made on your
> > feature branch, so is there really anything to discuss here?  (I asked
> > the question which led to this sub-thread because you mentioned that
> > you "start a new thread that does getaddrinfo".)
> 
> No, I wrote that that's what getaddrinfo_a does, so we could just do
> that ourselves and not have to rely on getaddrinfo_a.

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.

> >> Anyway, this reminds me of something that I've been wondering about gdb
> >> output when running Emacs.  It often says something like this:
> >> 
> >> warning: Corrupted shared library list: 0x84582e0 != 0x5104c30
> >> warning: Corrupted shared library list: 0x2f172a0 != 0x21688a0
> >> warning: Corrupted shared library list: 0x79f1910 != 0x21688a0
> >> warning: Corrupted shared library list: 0x79f1910 != 0x21688a0
> >> warning: Corrupted shared library list: 0x7a07ae0 != 0x21688a0
> >> 
> >> Is that something to be worried about, or is it...  normal?
> >
> > It's a real problem.  Crystal ball says that some of the system
> > libraries Emacs uses don't have debug info files to match them;
> > instead, you have debug info files from different versions of the
> > libraries.  Try "info sharedlibrary" at the GDB prompt, maybe it will
> > tell you which libraries are the offending ones.
> 
> Ok, but it's a problem when debugging in gdb, and not a problem for an
> Emacs running without gdb?

Only for the former, AFAIK.  GDB is complaining about a data structure
it builds, not about something the executable does.