From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: In memory Stream Date: Sat, 17 Feb 2024 15:28:54 +0100 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 17 Feb 2024 14:28:52 -0000 (UTC) Injection-Info: dont-email.me; posting-host="662d3d0c8c5c8e50d9cee14792db885b"; logging-data="483979"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19zCgUifEoytaLbXZfoRL5lqxgx66Ct5Sc=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:ysM8FgYCO/zUpz3/7ajdx9XFooM= Content-Language: en-US In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:66075 List-Id: 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