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: Emacs without threads Date: Fri, 15 Dec 2023 14:11:24 +0200 Message-ID: <83zfyboec3.fsf@gnu.org> References: <87il516pgm.fsf@ledu-giraud.fr> <83il51qbiy.fsf@gnu.org> <877clh6jky.fsf@ledu-giraud.fr> <83edfpq6os.fsf@gnu.org> <87v890vpo0.fsf@ledu-giraud.fr> <83cyv8rbdl.fsf@gnu.org> <874jgju3ia.fsf@ledu-giraud.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26244"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Manuel Giraud Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 15 13:12: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 1rE73F-0006bX-LA for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Dec 2023 13:12:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rE72O-0005g3-Ft; Fri, 15 Dec 2023 07:11:28 -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 1rE72M-0005fh-Vs for emacs-devel@gnu.org; Fri, 15 Dec 2023 07:11:27 -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 1rE72K-0000V8-Iv; Fri, 15 Dec 2023 07:11:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ayLIhoG2hptCyO+Ya4q2QtXp8Im2RqiSUyroKkuEFck=; b=ALNKZaWAhQCotAWtAHfy BZzwOlSFywtPdAJ9TZZaAM+lunVC6D84X1wtg5pNUAMGNd2Z2qehgYRYtLhRozfL46gmX0kgtnqw5 pl+VH2sXAvUvzQq3XSw8byqts4PDeEh2lVD3ZC1RWwUda9otdxaf7lq8pZqlPwIP9G1cREYEvIT+2 ay5cYwpyeFaZ4lzvf/LAZaFQfcAZ3RMx9nxNHvlHaxan/STQIshc4W5rpf4WPr/UlvB17AatdvMYU +Vh/6JWfFXx/q5+wOEEjFKPmnqaGqofSVm7P4R1p5Pwbk8DzArctJDUF/sJpSVl+GpdyrmqvkH+tk hJO+mavaEECwAQ==; In-Reply-To: <874jgju3ia.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 15 Dec 2023 12:08:45 +0100) 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:313855 Archived-At: > From: Manuel Giraud > Cc: emacs-devel@gnu.org > Date: Fri, 15 Dec 2023 12:08:45 +0100 > > Eli Zaretskii writes: > > >> From: Manuel Giraud > >> Cc: emacs-devel@gnu.org > >> Date: Thu, 14 Dec 2023 15:12:31 +0100 > >> > >> Eli Zaretskii writes: > >> > >> > The threads you see under a debugger are not Lisp threads, they are > >> > threads started by GTK and other libraries we link against. You > >> > cannot disable them, except by building Emacs without those libraries > >> > (I think just without GTK should do, if you are on GNU/Linux). > >> > >> I'm not using GTK so maybe it is another library (maybe librsvg-2). > > > > Look at the code those threads run (e.g., with "thread apply all bt"), > > and you will know which library does that. > > > >> >> (FWIW, I want this to simplify debugging because on my machine I cannot > >> >> make GDB to switch to the correct thread > >> > > >> > How come? > >> > >> I don't know so I will just describe the symptoms: when I "run" Emacs > >> into a 'M-x gdb' session at one point the *gud* buffer will output [New > >> thread ...] and then the Emacs process is stuck and so is the process of > >> the *gud* buffer. So I have to kill and close everything. > > > > Never seen anything like that. Any chance of describing under what > > conditions this happens? Is this 100% reproducible on your system? > > This is not 100% reproducible but it eventually happens most of the time > 😅. For example, if I put a breakpoint on 'show_mouse_face' and run > with -Q in gdb, I finally stuck like this at some point. Unless someone who uses GDB on X can confirm this problem, I'd say this is something to report to the GDB developers and/or the OpenBSD's GDB distro maintainers. Do you have any idea what code is run by those "New thread"s? If you start GDB from the shell prompt, not from Emacs, does this happen then as well? If not, this could be some bug in gdb-mi.el. > FWIW, I cannot set the scheduler-locking setting. Here is what I > get when I try: > > (gdb) set scheduler-locking replay > Target 'exec' cannot support this command. > (gdb) show scheduler-locking > Mode for locking scheduler during execution is "off". OFF is OK for debugging Emacs, but why do you think scheduler-locking is relevant to this issue?