emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asynchronous DNS


From: Lars Ingebrigtsen
Subject: Re: Asynchronous DNS
Date: Wed, 03 Feb 2016 11:42:57 +1100
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> 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?  Which nobody has proposed, anyway.

> 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.

>> 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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

[Prev in Thread] Current Thread [Next in Thread]