Re: In memory Stream

[DrPi <314@drpi.fr>]

Le 17/02/2024 à 15:28, Dmitry A. Kazakov a écrit :
> 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 ]
> 
In my use case, there is no performance problem.
The purpose is to make an editor simple instance. When you launch the 
editor the first time, everything is done as usual. Next time you launch 
the editor (for example by double clicking on a file in file explorer) 
the init code of the editor detects an instance of the editor is already 
running, transfers the command line arguments to the first instance and 
exit.
The buffer transfert occurs once when starting a new instance of the editor.

However, I keep your solution in mind. I might need it one day.
Thanks.