From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b9c9ba98cff47596 X-Google-Attributes: gid103376,public From: tmoran@bix.com Subject: Re: Message passing code Date: 1999/06/25 Message-ID: #1/1 X-Deja-AN: 493662879 References: <7kutrk$nkb1@svlss.lmms.lmco.com> X-Complaints-To: abuse@pacbell.net X-Trace: typhoon-sf.snfc21.pbi.net 930290917 206.170.24.25 (Thu, 24 Jun 1999 23:08:37 PDT) Organization: SBC Internet Services NNTP-Posting-Date: Thu, 24 Jun 1999 23:08:37 PDT Newsgroups: comp.lang.ada Date: 1999-06-25T00:00:00+00:00 List-Id: >I can see this causing problems, especially when someone creates their >Write routines to break up large objects into lots of small, discrete >objects. The data would probably need to be wrapped at a lower level, >and sent over as packets. This would cause some large objects to be >sent as many small packets, and this could be terrible, depending on I'm not clear on what you want, but if small packets from the many small 'Writes worry you, buffer them up. For writing one or more records as a single object to the clipboard, or writing it as a single datagram write, I use a data marshalling package which includes: -- Writes to a buffer will allocate additional memory from the -- heap as needed. If you know reasonably accurately how much -- you'll need, it will be more efficient to make the -- Initial_Length big enough and thus avoid heap allocation. -- -- Any heap allocation will be freed automatically when a Buffer -- ceases to exist. type Buffer_Type(Initial_Length : Ada.Streams.Stream_Element_Count) is new Ada.Streams.Root_Stream_Type with private; procedure Write(Stream : in out Buffer_Type; Item : in Ada.Streams.Stream_Element_Array); etc. Does that address (part of) the problem?