From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: In memory Stream Date: Sat, 17 Feb 2024 18:09:02 +0000 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="805b81416d070ad909fef11bbaf0e8d0"; logging-data="568167"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WeGz/t/U1uDPCeT2B0P+XEvJv5NNa5fY=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (darwin) Cancel-Lock: sha1:23krplbNwOYqE7vl/ta8XxjwMpY= sha1:mB0TjuaLUjfcGPz6OzlSEySqMmA= Xref: news.eternal-september.org comp.lang.ada:66079 List-Id: "Dmitry A. Kazakov" writes: > 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. Our motivation for the memory stream was the equivalent of this for UDP messages; GNAT.Sockets behaves (behaved?) exactly like this, so we buffered the result of 'Output & wrote the constructed buffer to the socket; on the other side, we read the UDP message, stuffed its contents into a memory stream, then let the client 'Input. I can't remember at this distance in time, but I think I would have liked to construct a memory stream on the received UDP packet rather than copying the content; the compiler wouldn't let me. Perhaps worth another try.