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: Thu, 06 Jul 2023 20:24:27 +0800 Message-ID: <878rbtkz2c.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <83v8ezk3cj.fsf@gnu.org> <87v8ezpov0.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <87pm57pns8.fsf@localhost> <87lefvp55t.fsf@yahoo.com> <87sfa28ura.fsf@localhost> <87cz16o8vz.fsf@yahoo.com> <87jzve8r4m.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> <87bkgq8p5t.fsf@localhost> <831qhmjwk0.fsf@gnu.org> <875y6y8nlr.fsf@localhost> <87h6qhnalc.fsf@yahoo.com> <87ilax71wo.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="6617"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 06 14:25:44 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 1qHO3M-0001ZE-5q for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jul 2023 14:25:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHO2P-00041A-4H; Thu, 06 Jul 2023 08:24:45 -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 1qHO2N-00040l-JS for emacs-devel@gnu.org; Thu, 06 Jul 2023 08:24:43 -0400 Original-Received: from sonic315-20.consmr.mail.ne1.yahoo.com ([66.163.190.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHO2L-0002rB-6V for emacs-devel@gnu.org; Thu, 06 Jul 2023 08:24:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688646279; bh=O0r+v43lkfwAwsJ8OayXU7b2nJvLQADuKN9GQ+KK/P4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=i+yvKItW6gNZ9JNXeHTYdHDtAWPuXxpdBbUT6I6cI/2i0CBagBbmsS8yHgykQgAHfzykEEEQph3zNSvotHVlzaJ13biLTqVK2h5EoqTbNZaM/WAFjpDcDeaeKy2x+XDNEq3SaGgda5QOZJsFlvndCwDB4SsAMprmhfeFK6MS8dUzrhJ5SzqiOzAETan28yDonX0YcUV8DI/V23U5JJbtHKBO9VC6dv9/EAmcT9iNyqwmp8SULrEWNVWV2e0MB3VYPzk3lBq6fFucbstHHQYWJFen6RLgFgd9gIeexbSy9vTQWeg1EZ9sV92QzrN2kPavQ7A8YQfEApy+gtO50kqQMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688646279; bh=wELvrgV8rktrRTifgbKcbHfJv7G2U/Cm61f3kkX94or=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=B+RQ4N56iSaMWtJ9R4lSoEBxkozYFRwdluY6vSrvCQxhBeY5UvTHsmyQzAbizfulhHgCH7nIiS+8QKFOZzuhISMnMW5Zno5Mv7wHXKCEYoLS3Sx5TIDlKDe6Ps2uhVXc9jrpSVkGBJsj7juFlBnw6s0ZYB5yTZfaPbX148TgHHbxSu6b7mADpUKFoeLiygjhFztQESPfwoh1SlU7DRMtrre3jOQ7h/EJ1V88xWYg9Y4GyOomq3GNCwjb0VbhL4BK/5okWzPJCBT3dYGpvw6qOiq1hcB2Cod8f32IU3lnHjO/63TF7gniOL8jVJBzh+GeFkSiPkx2AdN0g7Q1kc1YWA== X-YMail-OSG: 7_6Y.YkVM1kPdLwz6si2Fx2vLS1wKTpJ7sOihJyC90nREwR9RnwqedPv6jflEz1 RpomvtiHvZmtl9HS2TzllTNEgmSNkjkvQ8E7lmAV32ikP5FGAOB1geuUzGfNbqCawmIPW8uUjk57 7k2drTArTQDGoApIhQmsPsKVp_ezeJY.f_hX_PAZ3ma_jEl88SDgWU5uOj.DjdrAzvVq84KtMBLM 0FjC9KuOqygAQzPGjI3saVHEPBJbI25DCnbfx74DsQyIDwHg7Nbx6wUQLJbQ_7LoIHdBD76zB9uj C3TdtS3WGtAP_baHz.WSNlMTyx6Qi2P3h.vKAGD3BlXerD2JCLvCnqGNV7tKmB2iUA8BKYuh3kIi t5qwaJ58Tnon2Sc3j8YBpVl5mKAooobMLgdRfkOW6T6LhrNGBSB7w1vZSqbGtJp1WmyjLHMhHePW GRqtRiVuGqChnUOL4INOlhQCTC3ROW6w8ZmPsS7U9XfC3d4MJrJs6wSTWPc9X85YJ3OPQPrqxEtu oih8d4ILMU8J8hqXI0h4OdfcmoqwX4dSAO0nsIfm88m.b1QlIwVG9iy_ybCMNn36onvP_6FXaiEO 4CD_iNMd6vLdw9GNDrK.rWBp.aMzQ9ppd.YU0ltn1GlLuPfR1p63dK3sjwI.LRZj8jSuzoHPG_0L EESx0bCociZbXlte0TLab1LVp0zFnFa7zLQgdNcToXWqv9cr4tabpbpnsn72wrZk4jWiPAJCjbUy lCgext9XYFzdD7un8rFwPUV5lqfvFSCa7gzKnz7Pe.5CN67SGiR5oDb1nFj0sW4k485TKKIO_SWl DkHQ9N8VINTIsF.d_o9aC2b6ercj6BHEXRBWhDMV9w X-Sonic-MF: X-Sonic-ID: ab7ba8b5-5944-494a-8eac-75e8760f323f Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Jul 2023 12:24:39 +0000 Original-Received: by hermes--production-sg3-67fd64777-txbf9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bf194000c98cbdf1b9bd3c44d374a635; Thu, 06 Jul 2023 12:24:34 +0000 (UTC) In-Reply-To: <87ilax71wo.fsf@localhost> (Ihor Radchenko's message of "Thu, 06 Jul 2023 10:46:47 +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.190.146; envelope-from=luangruo@yahoo.com; helo=sonic315-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=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:307495 Archived-At: Ihor Radchenko writes: > I may be wrong, but from my previous experience with performance > benchmarks, memory allocation often takes a significant fraction of CPU > time. And memory allocation is a routine process on pretty much every > iteration of CPU-intensive code. > > I am afraid that interlocking object allocation will practically create > race condition between threads and make Emacs unresponsive. > > Or am I missing something? > Is there a way to measure how much CPU time is spent allocating memory? The detail of the interlocking can be increased if and when this is demonstrated to be problematic. Allocating individual Lisp objects usually takes a short amount of time: even if no two threads can do so at the same time, they will all have ample opportunities to run in between consings. > Would it be of interest to allow locking objects for read/write using > semantics similar to `with-mutex'? The problem is interlocking access to low level C state within objects and not from Lisp code itself, and also avoiding constructs such as: CHECK_STRING (XCAR (foo)); foo = XSTRING (XCAR (foo)); where the second load from XCAR (foo)->u.s.car might load a different pointer from the one whose type was checked.