From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Blocking calls and threads Date: Thu, 20 Apr 2023 10:19:11 -0400 Message-ID: References: <838ren6mpp.fsf@gnu.org> <83cz3y65ev.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3166"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 16:20:22 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 1ppV92-0000Qu-Iq for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 16:20:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppV8N-0003P4-14; Thu, 20 Apr 2023 10:19:41 -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 1ppV8D-0003La-0a for emacs-devel@gnu.org; Thu, 20 Apr 2023 10:19:31 -0400 Original-Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppV8A-00042O-2V; Thu, 20 Apr 2023 10:19:28 -0400 Original-Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-247399d518dso676612a91.0; Thu, 20 Apr 2023 07:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682000363; x=1684592363; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8PYTURtbl0crJp0XiKgaJPw/VVqmLrK1tCnUktDROpk=; b=N0EYGf4SQbcWnW0x+3bbysHnjrauI3eyqFyxBvohDOjS8hCrobw3+H2YxsLrB4Zg0R PdMTsw5Nu3edm7FYPSPoCoFGp9ZkeTqQApj771tJi6oVK/vXIF2N8X+yNNV+hDb8E7Qk ACxpz4Wt94J2WiDTv7e/8UF3IPWZbMPxeP7NcacEl0oy5hj+QqywXYRGmdjWLETjbGbv AIZO8+zIEIP7+wbbZx8sjFCQcS+AHLrzKVsIEg4vgL4wJj6t25fckGx+YKhZaldDCSbV bet9DzmY+JAtAtRWn8uDUhkeLk9EWyaz3phvoXJQ1OTi80WAslS5Q43xLgdIydjfX7xO 7Uhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682000363; x=1684592363; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8PYTURtbl0crJp0XiKgaJPw/VVqmLrK1tCnUktDROpk=; b=eeeAYXkCwe1dRsunL6sjtqiwnTXtjXWG/y6d9n1bnDU+VuMK3aIBTttzgEhSDcgBiD KXX2e+PYdhbrwF+jsSe0XV9CGYaUuYguvKoy7uSx5XKdR/PAO4UqHlRuNyWOWBF95N6Z bAoTrquYOieOoNCOeM+mmGpAQeijwwfgZeW2L67aISn4wFcS1C4BvsDuTz+w7tASktsM kAb9OLJ8Thi9FG+uVzLhmf5Yfx2bqVgSxfkEs+oFJAJ95izTqs6xtS/lLzZBMsQdgDNq nSFWf6WTeVLOcCL/IqmtCKxhG+6K7vFgUKLB/12RlIclfM8QUkm7qMpJQq3EKmFbJfnO JYUQ== X-Gm-Message-State: AAQBX9fLCLc7rdrmTdE8Ty5x7gFVQSw2KmOMDAElCZYxSnUaiguwWbuz OkF8CUqkYC+88TSsveitBxyDN+DSqS1x6sumwsyzVXwc X-Google-Smtp-Source: AKy350YNmdHF1PP3CZp/fPX+ZijEJ8uMzGuloQN++1jsZwaRbRCr37hrcDkwEi3DdXYlb0h7zpVEsCqA8kP6kYeGHUk= X-Received: by 2002:a17:90b:710:b0:249:7224:41bf with SMTP id s16-20020a17090b071000b00249722441bfmr1820987pjz.47.1682000363189; Thu, 20 Apr 2023 07:19:23 -0700 (PDT) In-Reply-To: <83cz3y65ev.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1030.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:305511 Archived-At: On Thu, Apr 20, 2023 at 9:37=E2=80=AFAM Eli Zaretskii wrote: > > 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. I don't know whether it's a good idea. I'm not sure how anyone can work out how to provide explicit but generic asynchronous programming constructs, as Stefan is, when some operations are implemented in ways that don't allow 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? You're talking about yielding the system thread, I'm talking about yielding the Lisp machine thread. Even though Lisp machine threads are implemented by mapping them to the underlying system thread, the Lisp machine execution state is kept coherent by the global (interpreter) lock. Releasing the lock is effectively yielding the Lisp machine thread. The system thread will yield implicitly if the read blocks. > > 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. So making "insert-file-contents" yield would introduce race conditions with respect to the buffer being read into that the lisp programmer choosing to use threads would have to be responsible for (which would be what Stefan is trying to simplify, I think). I don't mean lisp-machine violating race conditions - the read operation should either use some temporary buffer and copy into the lisp buffer, or wait for data to be ready, then reacquire the GIL before invoking the read syscall with a pointer into the Lisp buffer object. Lynn