[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we go GTK-only?
From: |
Eli Zaretskii |
Subject: |
Re: Can we go GTK-only? |
Date: |
Tue, 01 Nov 2016 19:15:31 +0200 |
> Cc: address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Tue, 1 Nov 2016 10:06:14 -0700
>
> On 11/01/2016 10:01 AM, Eli Zaretskii wrote:
> >> Cc: address@hidden, address@hidden, address@hidden
> >> From: Daniel Colascione <address@hidden>
> >> Date: Tue, 1 Nov 2016 09:45:41 -0700
> >>
> >> Name one system we support that both _has_ threads and that doesn't have
> >> a thread-safe system malloc. If we're using our own malloc and _that_
> >> isn't thread-safe, that doesn't count. I insist that on modern systems,
> >> the malloc and free that come with libc are thread safe.
> >
> > You can insist all you like, it won't change my mind: thread-safety in
> > malloc is only now becoming widespread and reliable enough, and older
> > systems where there are various bugs in that regard are still with us
> > in significant numbers. Just google the keywords, and you will see
> > the bug reports and their dates.
>
> Extraordinary claims require extraordinary evidence. Your claim is
> extraordinary: it's been common practice for _decades_ to make memory
> allocations from multiple threads in multithreaded programming.
This is simply incorrect. On _some_ platforms, that is true. But not
on all, not anywhere near that.
> > I think we've lost context: this thread is not about the concurrency
> > branch, where only one thread runs at a time, for which that Python
> > paper is irrelevant. This thread (or at least what I wrote above) is
> > about the proposal to have more than one thread that performs
> > CPU-intensive tasks, so that the main thread could go about its
> > business. For that, you will definitely want CPU preemption, because
> > those tasks don't have to run Lisp.
>
> If those CPU-intensive tasks are not written in Lisp, there is no need
> to hold the GIL while running them, so other threads can run Lisp in
> parallel.
CPU-intensive threads that cannot manipulate Lisp objects (not run
Lisp, but create and destroy Lisp objects) are not very useful in
Emacs.
- Re: Can we go GTK-only?, (continued)
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
Re: Can we go GTK-only?, Daniel Colascione, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
- Re: Can we go GTK-only?, Daniel Colascione, 2016/11/01
- Re: Can we go GTK-only?,
Eli Zaretskii <=
- Re: Can we go GTK-only?, Daniel Colascione, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
- Re: Can we go GTK-only?, Daniel Colascione, 2016/11/01
Re: Can we go GTK-only?, Stefan Monnier, 2016/11/01
Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
Re: Can we go GTK-only?, Daniel Colascione, 2016/11/01
Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01