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: Concurrency via isolated process/thread Date: Thu, 06 Jul 2023 20:53:47 +0300 Message-ID: <83leftgc44.fsf@gnu.org> 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> <87leftnat6.fsf@yahoo.com> <87fs6171uj.fsf@localhost> <83zg49gmgl.fsf@gnu.org> <87ttuhxejx.fsf@localhost> <83pm55gjaa.fsf@gnu.org> <87leftxaiz.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8684"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 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 19:54:11 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 1qHTBC-00022P-Uk for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jul 2023 19:54:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHTAr-0004pc-9M; Thu, 06 Jul 2023 13:53:49 -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 1qHTAp-0004nd-27 for emacs-devel@gnu.org; Thu, 06 Jul 2023 13:53:47 -0400 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 1qHTAo-0003lW-EH; Thu, 06 Jul 2023 13:53:46 -0400 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=CPghEDCJCd9s3U1WzlaYnzUzeQ9NoBXg5MdMl+ofkq4=; b=m0MBNPvmwWS7 +oBHKWmjvEcUXTxffDNjGhf7OwhlWNFL3lRUxcxRel6hJp0sF03GjR5HHVJa49/fRPlxlfYsbg01Z ffeVkO+dFGhDP2C56Z1GwsxTAGSh2c7OLeb43nbxHqq4BeAzvxLOKPeNbJ9HnOfdcg5iM5KxECC9s yhy3mewugsCTIXROwpWzMX8nTUqjent+h795JnoCGeMmw7dAXIZ4zotWpWRkQjqNqW/wJz8Ik1Y/v 1nLb0HjaZ8kQhAXEJbGxyBsy3OzGvYgw2B2GMCMi1V5TFV3tBOGvbiwAcNyMg3rHHBUUSw4rRM5A0 /txp+Wl9YYfgGHX3LZGZAA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHTAn-0007fc-Kt; Thu, 06 Jul 2023 13:53:46 -0400 In-Reply-To: <87leftxaiz.fsf@localhost> (message from Ihor Radchenko on Thu, 06 Jul 2023 16:36:04 +0000) 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:307525 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Thu, 06 Jul 2023 16:36:04 +0000 > > Eli Zaretskii writes: > > >> AFAIK, process communication is now implemented using buffers that, even > >> in the absence of coding system, index the data stream into byte array. > > > > Yes, but isn't binary data also a stream of bytes? > > It is, but storing that data in buffer will involve non-trivial extra > memory allocation. And in your memcpy idea, from where will the buffer come to which you copy? won't you need to allocate memory? Besides, if you need to insert reasonably small amounts of data, the Emacs buffer-with-gap model avoids allocating too much, sometimes nothing at all. > >> I am not sure if it is something that can be directly fed to memcpy (thus > >> avoiding too much of extra cost for passing Lisp data around). > > > > If you don't want the incoming data to be inserted into a buffer or > > produce a string from it, then what do you want to do with it instead? > > To use something in Emacs, we _must_ make some Lisp object out of it, > > right? > > What I had in mind is, for example, memcpy wide_int_object -> child > process -> memcpy to child process own heap. Emacs Lisp objects are never just one int. The integer you see in C are just a kind of handles -- they are pointers in disguise, and the pointer points to a reasonably large struct. > So that we do not need to go through creating a new wide_int object in > the child process. I don't see how you can avoid that. I feel that there's some serious misunderstanding here.