From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Blocking calls and threads Date: Thu, 20 Apr 2023 16:37:28 +0300 Message-ID: <83cz3y65ev.fsf@gnu.org> References: <838ren6mpp.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21122"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 15:37:57 2023 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 1ppUU1-0005GM-6E for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 15:37:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppUTO-0002A3-W2; Thu, 20 Apr 2023 09:37:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppUTM-000287-Qm for emacs-devel@gnu.org; Thu, 20 Apr 2023 09:37:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppUTM-0004Zk-IZ; Thu, 20 Apr 2023 09:37:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rYo5c3wn0Ah+mgoFIkahYXO6rKju6AX/yOFf+2QT4EQ=; b=hdHW2jBog7jj gJ93U3wf8vHsy3VWbsuYHDKUNlZRjJWeOLoPM/ysL3e8nH0JpRFZFR+gDoNWLL53R1A0C8ugKcM4v B45M7R1/VIMR1ja/PU2ICkHug/tPlo60IQVp1OVKIFK+ZQD9g75W0Kc5pNZspGJaK/kTHimok+jCe v0gkEdP7OVdt94j2wZixpevO17wjDb0uwNB+cb27fXqT+SRzIkhQVCippD9WwloS9+JY5eceLU3KH nqRkgMwWKe/+GbKAvGvjPdPvCdF7phSfsSTJ45RBUw/AqxyMDxEkOtmL2rlgbAzpZQWC41bIxYzpL 0xQIL33/h7i/gkZicC/70A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppUTL-0000zF-NT; Thu, 20 Apr 2023 09:37:16 -0400 In-Reply-To: (message from Lynn Winebarger on Thu, 20 Apr 2023 09:06:16 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305507 Archived-At: > From: Lynn Winebarger > Date: Thu, 20 Apr 2023 09:06:16 -0400 > Cc: emacs-devel@gnu.org > > > What do you mean by "blocking system calls", exactly? > > > > If you mean the likes of 'read' and 'write' (i.e. "blocking system > > calls" on the OS level), > > Almost - I mean the subrs that make those operations available to the > lisp machine, e.g. insert-file-contents. insert-file-contents does a lot of simple bookkeeping stuff, then calls 'read' in a loop to read the file and decode the stuff it reads. We could perhaps yield between reading and processing chunks (we don't in the current Emacs), but would it help? Modern systems are very fast in reading local files, so you'd make insert-file-contents and its callers much slower for no good reason. Likewise in write-region. > > then no, a thread which makes these calls > > will not yield. How can it? the implementation of those calls is not > > in Emacs, so how can Emacs change the way these syscalls work? > > Presumably whatever mechanism is used for the calls you identified > below could be generalized. In practical terms, it would mean > assigning locks to every system resource that isn't inherently part of > the lisp machine, in this case at least file descriptors. Then, for > example, the read call in emacs_intr_read (in sysdep.c) could be > surrounded by a release of the global lock (which yields the thread of > the lisp machine) and the re-acquisition of the global lock. The file > descriptor lock might be acquired after yielding the lisp thread, or > it might be owned exclusively by the thread that opened it. If you yield before issuing the system call, the system call will wait until you re-acquire the lock. So how will this help? To be effective, this needs to yield _after_ issuing the system call, so that the system call proceeds in parallel with Emacs doing something else. But since the system call is not implemented by Emacs, I don't see how this could be done? In a new non-Lisp thread that we would start to issue the system call from it? is that what you have in mind? But then we'd have the "usual" problem with Emacs: the huge global state that we have. That non-Lisp thread cannot use any machinery that changes the global state, nor call any Lisp or Lisp primitives, so it will only be able to do very simple processing, thus making the whole business much less beneficial, from the user's POV. > > The "blocking system calls" which do yield are calls emitted from > > Lisp: accept-process-output, sit-for, read-key-sequence, etc. > > Are these identified as a group anywhere for reference? Otherwise, I > don't know what is included in the "etc". Basically, anything that ends up calling thread_select, usually via wait_reading_process_output.