From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "concurrency" branch updated Date: Tue, 03 Nov 2015 18:23:03 +0200 Message-ID: <834mh3vyqg.fsf@gnu.org> References: <83pozsw35l.fsf@gnu.org> <83oafcw2v6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1446567805 5644 80.91.229.3 (3 Nov 2015 16:23:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 16:23:25 +0000 (UTC) Cc: raeburn@raeburn.org, emacs-devel@gnu.org To: Elias =?utf-8?Q?M=C3=A5rtenson?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 03 17:23:18 2015 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 1ZteMe-0007CG-Gh for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 17:23:16 +0100 Original-Received: from localhost ([::1]:49645 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZteMY-0003G8-Od for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 11:23:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZteMV-0003G3-Od for emacs-devel@gnu.org; Tue, 03 Nov 2015 11:23:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZteMR-0007S5-QD for emacs-devel@gnu.org; Tue, 03 Nov 2015 11:23:07 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:48878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZteMR-0007RR-Hp for emacs-devel@gnu.org; Tue, 03 Nov 2015 11:23:03 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NX800K00YS5GF00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 03 Nov 2015 18:22:48 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NX800KWMYU03X70@a-mtaout20.012.net.il>; Tue, 03 Nov 2015 18:22:48 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:193158 Archived-At: > Date: Tue, 3 Nov 2015 11:58:19 +0800 > From: Elias M=C3=A5rtenson >=20 > I started playing around with this branch a bit and I quickly disco= vered an > issue. If you have read the discussions to which I pointed, you know that this branch is not yet ready for play. > I wanted to take the opportunity of describing this issue while at = the > same time hopefully gain some insight into the design of the featur= e. >=20 > What I did was to write the following function: >=20 > (defun foo () > (loop for i from 0 below 10 > do (message (format "Message %d" i)) > do (sit-for 1))) >=20 > I then started this function in a thread: >=20 > (make-thread #'foo) >=20 > What happened was that the 10 messages were printed to the *Message= s* buffer > without any delay between them, and then the entire Emacs session b= ecame > incredibly sluggish. This works for me, at least in "emacs -Q". I don't see any of the abnormal behavior you describe. Did you try in "emacs -Q"? > Looking at the implementation of sit-for, it seems as though it end= s up calling > read-event on a different thread which is probably not a good idea. How do you see that? When I run your program under GDB, I see only one announcement of a new thread, when I evaluate the call to make-thread. Then I see a single announcement of thread exit, when the thread finishes counting to 10. I see no additional threads. In general, it would make very little sense for sit-for and/or read-event to start a new thread and run there, for fairly obvious reasons. What can happen when you call sit-for is a switch to another thread, if there is one. But in this case, I don't expect that to happen.