[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the state of the concurrency branch
From: |
Tom Tromey |
Subject: |
Re: the state of the concurrency branch |
Date: |
Tue, 27 Aug 2013 12:23:12 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
>>>>> "Paul" == Paul Eggert <address@hidden> writes:
Paul> On 08/27/13 09:08, Eli Zaretskii wrote:
>> . Why is systhread.c on a separate file? Wouldn't it be better to
>> have this code in thread.c instead? It's not like thread.c can be
>> compiled in without also compiling systhread.c, right?
Paul> Good point, and more generally, we should redo the code
Paul> so that there's not a separate sys_* level above a pthread_ level,
Paul> as the extra level's complexity isn't buying us anything.
Paul> I'll work on a patch along those lines.
I did this intentionally to separate out the system-dependent bits from
the lisp-level bits. I think it makes the porting simpler and it
prevents system oddities from infiltrating the lisp layer.
This latter bit is important because the lisp layer has specific
semantics, and there isn't always a 1:1 mapping from a lisp construct to
the underlying OS construct. E.g., lisp mutexes are interruptible,
whereas system ones are not.
Could you say what is wrong with it as it stands?
If you're concerned about the layer of indirection... well, first, don't
be, it hardly matters; but otherwise, you can just inline most of the
stuff in systhread.h if you really care. That would be ok with me.
Tom
- Re: the state of the concurrency branch, (continued)
- Re: the state of the concurrency branch, Stefan Monnier, 2013/08/26
- Re: the state of the concurrency branch, Juanma Barranquero, 2013/08/26
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/26
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/26
- Re: the state of the concurrency branch, Stefan Monnier, 2013/08/26
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/26
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/27
- Re: the state of the concurrency branch, Paul Eggert, 2013/08/27
- Re: the state of the concurrency branch,
Tom Tromey <=
- Re: the state of the concurrency branch, Paul Eggert, 2013/08/27
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/27
- Re: the state of the concurrency branch, Paul Eggert, 2013/08/27
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/27
- Re: the state of the concurrency branch, Paul Eggert, 2013/08/27
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/27
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/27
- Re: the state of the concurrency branch, Eli Zaretskii, 2013/08/27
- Re: the state of the concurrency branch, Tom Tromey, 2013/08/27
- Re: the state of the concurrency branch, Stefan Monnier, 2013/08/27