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: Concurrency Date: Mon, 29 Mar 2010 12:25:32 -0400 Message-ID: <0313BE4F-1CA1-4CFD-9CF9-ADA3AFF9ECF3@raeburn.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1269880343 932 80.91.229.12 (29 Mar 2010 16:32:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Mar 2010 16:32:23 +0000 (UTC) To: "emacs-devel@gnu.org discussions" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 29 18:32:19 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 1NwHss-00079D-GM for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 18:32:14 +0200 Original-Received: from localhost ([127.0.0.1]:39068 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwHru-0006Dd-I1 for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 12:31:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NwHmb-0003WA-JO for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:25:45 -0400 Original-Received: from [140.186.70.92] (port=53883 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwHma-0003U0-7h for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:25:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NwHmX-0006vG-Vf for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:25:44 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:54311 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwHmQ-0006tG-AP for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:25:41 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o2TGPWK5005813; Mon, 29 Mar 2010 12:25:32 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.1077) 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:122850 Archived-At: On Mar 28, 2010, at 17:17, Tom Tromey wrote: > * The current code makes no attempt to portable, it relies on POSIX > threads and the GNU __thread extension. This is not too hard to fix. > I think it is reasonably important to keep __thread on systems that > support it, for performance. =46rom what I understand, porting to Windows should be easy enough. "A = simple matter of coding." Dealing with __thread shouldn't be hard if it's not used pervasively, so = pthread_{get,set}specific calls can be used in its place. > * Suppose you have existing elisp that creates a process with a = filter, > and the filter changes a let-bound variable, and the "outer" elisp > blocks in sit-for waiting for the filter to do its thing. Nothing in > the current code guarantees that the process filter will be run in = the > "correct" thread. That may be a reason to force the filter to run in the same thread that = created it. Perhaps process filters could be run at thread-switch = opportunities like 'yield', too? (And vice versa -- perhaps calls that = permit the running of process filters should also permit thread = switching?) Sounds like this is coming along nicely! Ken=