[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
- Re: Asynchronous DNS, (continued)
Re: Asynchronous DNS, Eli Zaretskii, 2016/02/01
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/01
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/01
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/01
- Re: Asynchronous DNS, Stefan Monnier, 2016/02/02
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/02
- Re: Asynchronous DNS, Stefan Monnier, 2016/02/02
Re: Asynchronous DNS, Eli Zaretskii, 2016/02/02
Re: Asynchronous DNS,
Lars Ingebrigtsen <=
Re: Asynchronous DNS, Eli Zaretskii, 2016/02/03
Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/03
Re: Asynchronous DNS, Alain Schneble, 2016/02/04
Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/04
Re: Asynchronous DNS, Alain Schneble, 2016/02/04
Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/04
Re: Asynchronous DNS, Eli Zaretskii, 2016/02/05
Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/05
Re: Asynchronous DNS, Alain Schneble, 2016/02/13
Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/13