From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 03/10] introduce systhread layer Date: Mon, 13 Aug 2012 06:21:24 -0400 Message-ID: <9C928EA6-6467-422C-842B-9EA7E37C2A91@raeburn.org> References: <87mx23etza.fsf@fleche.redhat.com> <50246659.80200@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1344853295 19708 80.91.229.3 (13 Aug 2012 10:21:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Aug 2012 10:21:35 +0000 (UTC) Cc: Tom Tromey , Emacs discussions To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 13 12:21:36 2012 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 1T0rmA-0005F5-8w for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2012 12:21:34 +0200 Original-Received: from localhost ([::1]:45799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0rm9-0004J1-67 for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2012 06:21:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0rm5-0004Ip-2K for emacs-devel@gnu.org; Mon, 13 Aug 2012 06:21:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0rm3-0003h0-W4 for emacs-devel@gnu.org; Mon, 13 Aug 2012 06:21:29 -0400 Original-Received: from mail-gh0-f169.google.com ([209.85.160.169]:44460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0rm3-0003gv-Rm for emacs-devel@gnu.org; Mon, 13 Aug 2012 06:21:27 -0400 Original-Received: by ghrr18 with SMTP id r18so3000261ghr.0 for ; Mon, 13 Aug 2012 03:21:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=1vjLhMc6w91C5eaXz7v1reI/GtPXDnhnabJUt7jasxE=; b=I4jVnKQU1rK1N7haXqYXHgaTKJ+kUzda0/Oe7R9tPAH3yVJPUWxth7DQPTD9mMgl4A rcZtB6LD/Fov/U+dBllLe9qDf8A+eb5PJOviAA0vz6MU0ajHaz0X7Wk33yMPRqnluI4q unUH37KCILalhtdbiNUb9CNVd0d6j0D0jw4YyK+59Wff7jagSjAnWZy2MvSMjLWfPaof OJRpnaqs1+cQbNBY90qqD5eVuddAU8X6NEaGsUcu9NBWezMGlQXyDbvz0G6u3wDNo3Ol yR3CfLTuhmHCvEuqIzcl2PyCOB/WXH9FVQiwSBvkIFnXsJVFUvPL2Jxad0YjXfyRaJAd th1A== Original-Received: by 10.50.186.131 with SMTP id fk3mr4715336igc.31.1344853286629; Mon, 13 Aug 2012 03:21:26 -0700 (PDT) Original-Received: from [10.0.0.158] (c-66-31-202-94.hsd1.ma.comcast.net. [66.31.202.94]) by mx.google.com with ESMTPS id q1sm13256459igj.15.2012.08.13.03.21.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2012 03:21:26 -0700 (PDT) In-Reply-To: <50246659.80200@dancol.org> X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmQy/SIy9Cp5DphpkOTpJuHi5qW4TKvl9H+StAcqktE5QTeje/VdPm8REqBNFA76CYQB1n4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.169 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:152467 Archived-At: >=20 > On 8/9/2012 12:38 PM, Tom Tromey wrote: >> This introduces the low-level system threading support. It also adds >> the global lock. The low-level support is a bit over-eager, in that >> even at the end of the present series, it will not all be used. I >> think thiat is ok since I plan to use it all eventually. >>=20 >> I've only implemented the pthreads-based version. I think it should >> be relatively clear how to port this to other systems, though. >>=20 >> I'd also like to do a "no threads" port that will turn most things >> into no-ops, and have thread-creation fail. I was thinking perhaps >> I'd make a future (provide 'threads) conditional on threads actually >> working. Thoughts on this? Unless there's a platform where the support isn't possible, I'd suggest = not doing this last bit, so that Emacs code (both Lisp and C) can assume = threads are available. Otherwise, either you can't use threads at all = in the release, which means that code won't be exercised very well, or = you write code that has to cope with both modes (which may simply mean = crippling some features when threads aren't available, and ensuring that = the rest of the code still works properly without those features), and = probably only really gets tested well in the mode where threads are = available. What benefit do you think providing this "no threads" port would have? On Aug 9, 2012, at 21:39, Daniel Colascione wrote: > If threads don't execute simultaneously anyway (and if I understand = your design > correctly, the global lock ensures they don't), then it might be = worthwhile to > also support a "green threads" implementation like GNU Pth or Windows = fibers in > order to avoid OS-level context switch overhead. Where every I/O operation needs to be rewritten to call some helper = function that do the thread switching? That sounds like a fine way to = make the code really ugly. :-( I think, too, we'd probably want support = libraries (X11, image or sound processing, TLS, etc) to be able to do = their thing (I/O, parsing, encryption) while another thread runs Lisp = code, and if those libraries aren't written to use Pth or whatever, that = won't happen. I've worked on code where performance of the thread-switching support = was a big deal. I don't see Emacs falling into that category, at least = not any time soon. On the other hand, I do hope that people find more = uses for thread support than occur to me right now, so=85. Ken=