Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Thu, 06 Jul 2023 16:36:04 +0000
> 
> Eli Zaretskii <eliz@gnu.org> 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.