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: Some experience with the igc branch Date: Sat, 28 Dec 2024 10:06:07 +0200 Message-ID: <86v7v4ut8w.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <86a5cj2a0e.fsf@gnu.org> <867c7n28sf.fsf@gnu.org> <877c7n962e.fsf@gmail.com> <8634ib24gp.fsf@gnu.org> <875xn75w7u.fsf@gmail.com> <86ttaryn1x.fsf@gnu.org> <877c7mzxbw.fsf@gmail.com> <861pxuzt61.fsf@gnu.org> <87wmfmy6mq.fsf@gmail.com> <86ttaqxybk.fsf@gnu.org> <867c7ly2v8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12862"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 09:06:47 2024 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 1tRRqR-0003AY-J7 for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 09:06:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRRpu-0002sP-Ee; Sat, 28 Dec 2024 03:06:14 -0500 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 1tRRps-0002sH-Bj for emacs-devel@gnu.org; Sat, 28 Dec 2024 03:06:12 -0500 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 1tRRpq-0004qi-TY; Sat, 28 Dec 2024 03:06:10 -0500 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=q5J+RxkoARf5mdHhIRplt7X4xoxtGjmf27mTbIpkApY=; b=Z2XbgNCdH6om 8GRHUMEQF0EbOI7fOX/JZm77TENWbEZz3HGRDFdTHjfYrOuIPPh1YM8c27H/C6hdQPr9Z8mQqWB22 iNNxrmRJWgVPn175zPkD+7u5eQNUDElVWHx7KGVek0qOPXs1xzV0Vcn0bMysGUi1xzc0j5fy7IY/K qK1DxMWZ+iCXwvcIzSHgxMh5vlD9nigK0kaq3RmoW3CLg7JxE2oTDbhhG59tN8I6YJufkNWbH5F97 k0BcqFYyeGvpPRR+e3KRdgj2tacw2nQhqY1rZqSub9Apc6MH2mGb65oULUOjhphOxojPNZ1Zopq8y 9+KmlBfs9WI08+WPC2nf9w==; In-Reply-To: (message from Paul Eggert on Fri, 27 Dec 2024 11:34:12 -0800) 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:327239 Archived-At: > Date: Fri, 27 Dec 2024 11:34:12 -0800 > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, > emacs-devel@gnu.org > From: Paul Eggert > > > Can you tell what happens during the short window between the signal > > being delivered to a thread and until it is redirected to the main > > thread? Specifically, are the threads other than the one which git > > hit by the signal still running until pthread_kill stops the main > > thread? > > Yes, the signal handler runs in whatever thread the OS decides to > deliver it to. While the handler runs, all other threads proceed > normally. If the handler happens to run in a non-main thread, all it > does is block the signal (so that its thread isn't bothered again by the > same signal) and then use pthread_kill to resend the signal to the main > thread. The handler then returns, which allows the non-main thread to > proceed; if the non-main thread was in the middle of a syscall, that > syscall may fail with errno==EINTR. And when the thread to which the OS delivered the signal calls pthread_kill to deliver the signal to the main thread, does that stop only the main thread? That is, do other threads keep running? > > So what happens if, when the signal arrives, the main thread is stuck > > in acquire_global_lock trying to take the global lock while some other > > Lisp thread runs? > > I don't know how Lisp threads work. But if they are OS threads, then if > the other thread has the lock, the main thread will remain stuck until > the other thread releases the lock. Really? Why? The main thread is stuck in taking a mutex, which AFAIU is a system call? Then delivering a signal to the main thread should terminate the syscall, and the main thread should execute the handler code for the signal it got delivered, no? (And yes, Lisp threads are OS threads; in particular, on Posix systems they are pthreads threads.) > > our profiler cannot profile non-main Lisp threads, because SIGPROF will > > always sample the state of the main thread? > > Yes, but that's not the only reason. A quick look at the profiling code > suggests that it is not thread-safe, so chaos would ensue if SIGPROF > were not forwarded to the main thread. "Not thread-safe" in what way? Only one Lisp thread can run at a given time, so some thread-safe issues should not exist in that case.