From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Mon, 10 Jul 2023 20:13:50 +0800 Message-ID: <87o7kkc6bl.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> <83a5w6cwdr.fsf@gnu.org> <87pm518m0g.fsf@localhost> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> <83cz119lxu.fsf@gnu.org> <87v8et6q5m.fsf@localhost> <838rbp9h6c.fsf@gnu.org> <87edlg6m2l.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26037"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 10 14:15:07 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 1qIpnH-0006Wl-BS for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Jul 2023 14:15:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIpmM-0008TW-3P; Mon, 10 Jul 2023 08:14:10 -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 1qIpmL-0008TN-4d for emacs-devel@gnu.org; Mon, 10 Jul 2023 08:14:09 -0400 Original-Received: from sonic316-20.consmr.mail.ne1.yahoo.com ([66.163.187.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qIpmJ-0002br-5k for emacs-devel@gnu.org; Mon, 10 Jul 2023 08:14:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688991242; bh=oHS++6bD1M2HcENkYsnA67GGWjfI82cS4zGbcJGAYvo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=ArnLioSPcpt5jRkohG0T/zaBLfjD6HhUbJMk0kBK/KoGwYweZOlik+2V6PFnleuJdw7jR1q469FJJU/W/Jyt0YgP9mcdmv8tLPGqvs00sI0Fmt7F6MeDxqOYSdPP3xvgYaZO7WgjeFrpQ/5QI2AkMoI65Pgtu1W/wgjcvAlE5Oe0hNn1FvSYGOjiZ0YAn4WfJeU0SsRWpp9WOtLjvx/ltvFNShvX/Fbmvgrd413usnVGhxHZQ6Cedt1qyCVc0FSL/F6dgWVlEuTg/dOTNmHV+UwxMNlezXBH492PGfhzfNwy+f6UkUPhTMaGzdCfcF2TRGmnZxZMofS0RSvK15Yqzw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688991242; bh=b2vXGrf3+eRuEGngtshJekElAtXOAcfFstZFvdd/0zT=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Fzdput6dFklEU/ZYh8/JVU0CpbrC4aJHTZH7DgB4cWJaSd45r/M8YzdL3GLA0lOYp5rfNvCs/p5hwcPAckDyuEbcSDecW2Jw/F5cf+l+fX7C+TieU9tWUlvZ2/xMILrN0KoN8KQCi92C/f/AtccLmG1dj5Oq1by5EMqUmr2+BYb/T8y2eX2awLK6zVrnXurihydWADZ42rI3OkvKs1w0du2ufIMV23Py3nThg7ZVpnxWEAYCwDAU4+PuHcQiuMhoIq4rV7nedf0SkWORUNfGXARp8iNyV3R6WwCNNtDfR3XoFgg32G9kXaFp9CbnM7aEICGFj6DROU8GhzpaT6Ry2A== X-YMail-OSG: jIdH3a0VM1lneKxNo8zWGzsjAM5ounTzRJrehEuVxR_B4VdU5_9wGw4IhZ7uc91 mIanyyjlvt.a55ZYBFcIvrMLruf7PYWjuoJ2AJ03ZZ7Fxo.EIXDjHAIUDO9ybEmsa77TnKAromNf 5R32ZxhK9kL.STrYiCfbAQVcqnmdp5jssgDumfEYkhQhkC0CCArfPv1moBAglwWza4Hm2.lBOJjH z0Pb.l_Fkfr4KR84r.vxGHGngDS7EeLf4Izn5T6zrreWcUuPGeUIAuTA.rtze5wGCki6rDcE.1wN 8YXbErvZrgQ3.sKWqhfQGGEFg4CaalBl6JyGFO.xx7jvThekLnHYclu_QGoQpY8vprRYdqOLBbRt sGV7hYuft1qarlQ6PCMMiBekI.MfoPoKu6_enQ5UmpESVqKQ4QJysRr6R6vKizSm8VL5Qz2LfFXw KcaAzvhCmWz44DvK3e7opvtjqAeWEvKxQsjsgDM1Adxt.v9FB02AbupEwooAcxnbwOaDI8iEo4NU ZgMZStdlJUNNqEh5xUvShZin1fx1Wr3Km8t9E70m0V.rmYHz1RhUGqOe_nR3zl6SKoKFatSbyTOD Gs5hQZY__x6cCSlLr3o_FYWSdLgqoayWr2D0K_71SwIrNttZNjDqxduxm_G0U9gDWBmccbs8DQqT 0yKtqEvQ7jSZgdgIjt8KSsrjZyB3VY33p4XUMQjewUrulq7KHxc1fGjPZALqf2Yih1WoI.7r0u0t 3AadaTpoxCmZmrXsJKOfdricCIoVMit3_q2Newgf7AaJ4_8mFdvqvzo45SETiX4B.5pyokWUh1kO e90VjU0FGBv4qEsVwiq0V_MJXalX03DG6.uq_yaaIN X-Sonic-MF: X-Sonic-ID: 99a93784-a237-492f-b991-c22b054a0394 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Mon, 10 Jul 2023 12:14:02 +0000 Original-Received: by hermes--production-sg3-67fd64777-rc8tr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2526ecec1ca027e18931a9c146a6e5bd; Mon, 10 Jul 2023 12:13:55 +0000 (UTC) In-Reply-To: <87edlg6m2l.fsf@localhost> (Ihor Radchenko's message of "Mon, 10 Jul 2023 11:30:10 +0000") X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.187.146; envelope-from=luangruo@yahoo.com; helo=sonic316-20.consmr.mail.ne1.yahoo.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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:307714 Archived-At: Ihor Radchenko writes: > I see. > AFAIU, we can then raise a flag that GC is necessary, so that other > threads will stop next time they reach maybe_gc, until GC is complete. What if even one of those other threads never calls maybe_gc? This can easily happen if they are blocked by a long running operation (domain name resolution comes to mind) and will result in all threads waiting for it to complete, defeating the purpose of having threads in the first place. TRT on GNU and other Mach based systems (OSF/1, OS X, etc) is to suspend all other threads using `thread_suspend' and then run GC from whichever thread is the first to discover that the consing threshold has been exceeded. Unix systems typically provide other platform specific functions to suspend threads or LWPs. As a consequence of this approach, GC can take place even if those other threads hold pointers to relocatable string data and buffer text. I've experimentally verified that this is rare, and that not compacting string blocks which are referenced from the stack or in registers doesn't significantly affect string data fragmentation.