Re: In memory Stream

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2024-02-17 14:36, DrPi wrote:

> Concerning the OS and the buffer transfert mechanism, as I said, this is 
> under control. I use Windows and the WM_COPYDATA message.
> 
> My usage is a bit special. The writing process writes a bunch of data in 
> a memory buffer then requests this buffer to be transferred to another 
> process by way of WM_COPYDATA. The receiving process reads the data from 
> the "new" memory buffer. I say "new" since the address is different from 
> the one used in the writing process (of course it can not be the same).

You ask Windows to copy a chunk of memory from one process space into 
another, so yes it is physically different memory. Different or same 
address tells nothing because under Windows System.Address is virtual 
and can point anywhere.

As you may guess it is a quite heavy overhead, not only because of 
copying data between process spaces, but also because of sending and 
dispatching Windows messages.

Note, that if you implement stream Read/Write as individual Windows 
messages it will become extremely slow. GNAT optimizes streaming of some 
built-in objects, e.g. String. But as a general case you should expect 
that streaming of any non-scalar object would cause multiple calls to 
Read/Write and thus multiple individual Windows messages.

An efficient way to exchange data under Windows is a file mapping. See 
CreateFileMapping and MapViewOfFile.


https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createfilemappinga


https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffile

Then use CreateEvent with a name to signal states of the stream buffer 
system-wide. Named Windows events are shared between processes.


https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createeventa

[ This is how interprocess stream is implemented for Windows in Simple 
Components ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de