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: Concurrency Date: Sun, 28 Mar 2010 20:20:04 -0600 Message-ID: References: <27349166.post@talk.nabble.com> <27560255.post@talk.nabble.com> <4B754E74.8060705@swipnet.se> <27563610.post@talk.nabble.com> <4B7564C7.1010309@swipnet.se> <27564728.post@talk.nabble.com> <4B756FB7.3050202@swipnet.se> <87k4ui4gik.fsf@lola.goethe.zz> <27566385.post@talk.nabble.com> <87wryi2sjd.fsf@lola.goethe.zz> <27585994.post@talk.nabble.com> <87k4ucdmwh.fsf@stupidchicken.com> <87d3zweq4e.fsf@master.homenet> <87y6hg1h4a.fsf@thor.thematica.it> <87tys3j9fa.fsf@lifelogs.com> <87eij6tqmu.fsf@lifelogs.com> <4BAFC93B.3010708@censorshipresearch.org> Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269829457 31020 80.91.229.12 (29 Mar 2010 02:24:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Mar 2010 02:24:17 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 29 04:24:11 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nw4eA-0000LT-QP for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 04:24:11 +0200 Original-Received: from localhost ([127.0.0.1]:53646 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nw4eA-0006eZ-6d for ged-emacs-devel@m.gmane.org; Sun, 28 Mar 2010 22:24:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nw4aK-0003FI-Qb for emacs-devel@gnu.org; Sun, 28 Mar 2010 22:20:12 -0400 Original-Received: from [140.186.70.92] (port=33927 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nw4aJ-0003E3-N0 for emacs-devel@gnu.org; Sun, 28 Mar 2010 22:20:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nw4aI-0001dj-8A for emacs-devel@gnu.org; Sun, 28 Mar 2010 22:20:11 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:49359) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nw4aH-0001de-U4 for emacs-devel@gnu.org; Sun, 28 Mar 2010 22:20:10 -0400 Original-Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2T2K60e000330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 28 Mar 2010 22:20:06 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2T2K6Oj003478; Sun, 28 Mar 2010 22:20:06 -0400 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o2T2K5kd012157; Sun, 28 Mar 2010 22:20:05 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id EC46488852D; Sun, 28 Mar 2010 20:20:04 -0600 (MDT) X-Attribution: Tom In-Reply-To: <4BAFC93B.3010708@censorshipresearch.org> (Daniel Colascione's message of "Sun, 28 Mar 2010 17:25:15 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122838 Archived-At: Daniel> In writing a different cooperatively-multitasked system, I've found that Daniel> I needed a kind of wait queue ("condition variable" if you will). While Daniel> you can build one out of the above primitives, it'd be better to provide Daniel> it as a part of the standard library. We purposely kept the API as minimal as possible. E.g., there isn't even a user-visible thread object. It is no trouble to add things, it just must be done thoughtfully, and in particular with an eye toward not breaking the possibility of preemptive threading. On this particular point, I agree, condition variables will be required sooner or later. Tom