From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: the state of the concurrency branch Date: Tue, 27 Aug 2013 11:39:11 -0700 Message-ID: <521CF24F.9020703@cs.ucla.edu> References: <87vc2t7erx.fsf@fleche.redhat.com> <83txicffpe.fsf@gnu.org> <87haeb3lwp.fsf@fleche.redhat.com> <83mwo3f762.fsf@gnu.org> <521CEA4D.9040900@cs.ucla.edu> <8738pv0z8v.fsf@fleche.redhat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1377628778 1277 80.91.229.3 (27 Aug 2013 18:39:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 18:39:38 +0000 (UTC) Cc: lekktu@gmail.com, Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 27 20:39:39 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 1VEOB0-0003pn-AC for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2013 20:39:38 +0200 Original-Received: from localhost ([::1]:57926 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEOAz-0007PW-PM for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2013 14:39:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEOAq-0007Ov-Td for emacs-devel@gnu.org; Tue, 27 Aug 2013 14:39:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEOAj-0003BU-KT for emacs-devel@gnu.org; Tue, 27 Aug 2013 14:39:28 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:43966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEOAb-000380-Op; Tue, 27 Aug 2013 14:39:13 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 981A339E8116; Tue, 27 Aug 2013 11:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgqjaVnPRCai; Tue, 27 Aug 2013 11:39:12 -0700 (PDT) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 10DC939E80F8; Tue, 27 Aug 2013 11:39:12 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 In-Reply-To: <8738pv0z8v.fsf@fleche.redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:163055 Archived-At: On 08/27/13 11:23, Tom Tromey wrote: > Could you say what is wrong with it as it stands? It's that there are two sets of functions where there needs to be just one. Where there's a need for a separate level for the Lisp layer (e.g., the stuff in sys_thread_create) that should be kept. But there's no need to distinguish (say) sys_thread_equal from pthread_equal. If there's a need for Emacs to port to OS threads that are not compatible with pthreads, we should use GNU Pth, rather than reinventing the wheel. > 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. It's not the inefficiency I'm worried about, it's just that the extra layer makes the code harder to read and understand, and doesn't buy us anything. But I hear what you're saying about the system-dependent bits and will try to preserve that in the proposed patch. > I presume the modified code will still leave a place for a > non-pthreads implementation, right? Sure, platforms without pthreads will still work.