From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Questions about throw-on-input Date: Mon, 11 May 2020 19:39:33 -0700 Message-ID: <742c0a6f-fc4c-6ac1-0233-85ad8671e199@dancol.org> References: <72ec0924-42f3-9f55-7edb-b2f9b678f707@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="74136"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: eliz@gnu.org, yyoncho@gmail.com, emacs-devel@gnu.org To: Alexander Miller , monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 12 04:41:55 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYKrj-000JBi-I8 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 04:41:55 +0200 Original-Received: from localhost ([::1]:33774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYKri-0000Lu-G7 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 22:41:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYKpb-0007VE-1x for emacs-devel@gnu.org; Mon, 11 May 2020 22:39:43 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54386) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYKpZ-0000Nt-SA; Mon, 11 May 2020 22:39:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jD9qTVKU3E+pYHwrQPwUNghTGnUjFgnEk+PgKRtZZJ0=; b=WpkQB3WKtROZTIkd7Pf/N5Vy8W srCce1khhADgN7ni7uPMXbWZfyGwAsxaCT88HjMxYt3SB1TGAf4G5i3pzT2hskXT9YstrvRbf69ep n+Lm3fv9SI9joflvv/dGdydXxqsPV+J6nUoviI+1gVJn/pRSs7gYlxORRDK6AbnIG99HJ/dLcHLAU sunDs5LvQ0lZFUKy7eG5+2kNMBggPsQLAPuFElECdy8dfT1MmUMr7FQRDQxRnPqUwpg9goJdZbUAW g+5Vu6QfIQJmjUhoqpG7xxfOCUCgWnU2Blu3N9NcnaHfo/VUEyIeqFJ/jxKs8bGhJ64tzXsjV65YS SlcSvh8A==; Original-Received: from [2604:4080:1321:9a00:519a:d934:f5c4:db2e] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jYKpS-0002cO-KL; Mon, 11 May 2020 19:39:34 -0700 In-Reply-To: <72ec0924-42f3-9f55-7edb-b2f9b678f707@web.de> Content-Language: en-US Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fedf:adf3; envelope-from=dancol@dancol.org; helo=dancol.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:249917 Archived-At: On 5/11/20 10:39 AM, Alexander Miller wrote: > >> Do we want that? > > > > I don't know. But hanging because `select` doesn't return the needed > > information doesn't seem right either. Maybe rather than signal an > > error, we should somehow make the main thread run that code, so as to > > return the right answer? > > That could be a game-changer, it would open up the path for making Elisp > a lot more asynchronous than it is now. You could load up heavy work on > a background thread, and (of course assuming it can be slit into smaller > pieces) simply yield whenever input is detected. Sure. You can also have Emacs run itself as a subprocess. > And while we are on the topic of threads, I wonder what is the > maintainers' opinion on https://nullprogram.com/blog/2018/05/31/, > specifically this part: > > > Update: ThreadSanitizer (TSan) quickly shows that Emacs’ threading > > implementation has many data races, making it completely > > untrustworthy. Until this is fixed, nobody should use Emacs threads > > for any purpose, and threads should disabled at compile time. Is TSan is just getting confused by the global lock? We don't have any parallelism, so data races shouldn't be happening at all.