[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for fields of `struct buffer'
From: |
Lennart Borgman |
Subject: |
Re: Patch for fields of `struct buffer' |
Date: |
Tue, 1 Feb 2011 18:08:43 +0100 |
On Tue, Feb 1, 2011 at 5:19 PM, Stephen J. Turnbull <address@hidden> wrote:
>
> Well, that's actually what I was asking Daniel. I'm not sure how
> illiterate you think you are, so please try not to be insulted if it's
> all too basic.
Oh, it has been a pleasure reading your answer.
> The problem with threads as I see it, and I believe this is why
> Richard and Guido express pessimism too, is that Lisp objects tend to
> get all linked together. Tasks that follow the links and mutate the
> objects are likely to interfere with each other, but that is a very
> common pattern in dynamic languages. In Python, this is handled with
> the GIL, or global interpreter lock.[1] In many circumstances, a thread
> must grab that lock, excluding all other threads from running. This
> also is somewhat expensive in terms of CPU AIUI. Many proposals have
> been made to remove the GIL from Python, but (so far) they all fall
> down because it turns out that keeping track of lots of "local" locks
> is either very expensive, or deadlock-prone. (The "STM" that I
> mentioned in connection with Haskell and Simon Peyton-Jones is more or
> less a technique for automatically managing "local" locks, and has
> been applied successfully in some projects.)
Thanks, I see. Isn't that problem there also with Tom's proposal of a
per thread-pointer for global vars?
Re: Patch for fields of `struct buffer', Richard Stallman, 2011/02/01