From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: the state of the concurrency branch Date: Tue, 27 Aug 2013 12:23:12 -0600 Message-ID: <8738pv0z8v.fsf@fleche.redhat.com> References: <87vc2t7erx.fsf@fleche.redhat.com> <83txicffpe.fsf@gnu.org> <87haeb3lwp.fsf@fleche.redhat.com> <83mwo3f762.fsf@gnu.org> <521CEA4D.9040900@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1377627816 22902 80.91.229.3 (27 Aug 2013 18:23:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 18:23:36 +0000 (UTC) Cc: lekktu@gmail.com, Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 27 20:23:38 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VENvV-00087b-R1 for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2013 20:23:37 +0200 Original-Received: from localhost ([::1]:57867 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VENvV-0003AI-Dj for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2013 14:23:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VENvN-0003A1-Rk for emacs-devel@gnu.org; Tue, 27 Aug 2013 14:23:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VENvI-0006Df-VM for emacs-devel@gnu.org; Tue, 27 Aug 2013 14:23:29 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:26881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VENvI-0006DZ-MY; Tue, 27 Aug 2013 14:23:24 -0400 Original-Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7RINEtK000997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 14:23:14 -0400 Original-Received: from barimba (ovpn-113-142.phx2.redhat.com [10.3.113.142]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7RINC1l030287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Aug 2013 14:23:13 -0400 X-Attribution: Tom In-Reply-To: <521CEA4D.9040900@cs.ucla.edu> (Paul Eggert's message of "Tue, 27 Aug 2013 11:05:01 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163052 Archived-At: >>>>> "Paul" == Paul Eggert 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