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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8ab6ed0f71c479cd X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!w22g2000yqd.googlegroups.com!not-for-mail From: george.priv@gmail.com Newsgroups: comp.lang.ada Subject: Re: API design problem - buffer scatter I/O Date: Sat, 22 Nov 2008 11:43:47 -0800 (PST) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 151.196.71.114 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1227383027 28276 127.0.0.1 (22 Nov 2008 19:43:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 22 Nov 2008 19:43:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: w22g2000yqd.googlegroups.com; posting-host=151.196.71.114; posting-account=VnNb3AoAAACTpRtCcTrcjmPX7cs92k1Q User-Agent: G2/1.0 X-HTTP-Via: 1.1 SPARKS X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092816 Iceweasel/3.0.3 (Debian-3.0.3-3),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:2752 Date: 2008-11-22T11:43:47-08:00 List-Id: On Nov 22, 11:05=A0am, Maciej Sobczak wrote: > I have a problem finding the best, from the Ada point of view, > interface for the scatter I/O API. > > The idea is that the library is able to read some bytes from somewhere > and put them in the buffers provided by user. The simplest, single- > buffer version of this idea is used in the standard library and in > many others - an example from GNAT.Sockets looks like here: > > procedure Receive_Socket > =A0 =A0 =A0(Socket : Socket_Type; > =A0 =A0 =A0 Item =A0 : out Ada.Streams.Stream_Element_Array; > =A0 =A0 =A0 Last =A0 : out Ada.Streams.Stream_Element_Offset); > > In other words, user provides a single array and the library fills it > with data. > > The problem is that this is a single, continuous array. > How would you approach the design of API for multi-buffer I/O? Multi- > buffer means that the user can provide many arrays, probably of > different sizes, and the library will fill them from first to last. > > The following assumptions are true: > 1. The user knows up-front how much data will be read. It will never > be less, so there is no need to give back any Last index, like above. > The user has to only ensure that the sum of buffer lengths is > appropriate for all the data that will be read. > 2. Buffers don't need to have the same size. > 3. Individual buffers are not necessarily related (they don't have to > be components of common bigger structure like record or array). > 4. It really has to be a single operation, so no cheating with > repeated calls for separate buffers to get consecutive fragments. > > My initial idea was that the subprogram might have a parameter that is > an array of access values to separate buffers (actual buffers must be > therefore aliased). Are buffer bounds properly handled when only > access to array is given (didn't check that yet, sorry)? If API library is written in Ada should not be a problem, you will provide it with thick pointer that it can handle as good as an operand. > > My initial idea: > > type Buffer_Ptr is access Ada.Streams.Stream_Element_Array; > type Buffers is array (Positive range <>) of Buffer_Ptr; > Hard to tell given limited information about your problem. I use to have somewhat similar problem in the past, but it was more challenging since communication part could do only some buffers at the time and I needed to provide some signaling when (and which) buffers were filled asynchronously. > procedure Scatter_Input_Data (B : in Buffers); > > What is bothering me is Types/access> and the discussion on designated vs. nominal subtypes in > the "Fat pointers" paragraph. The paragraph is stating that thick pointers may not be equivalent of memory location like in some other languages. That will matter when you plan to use subprograms written in these languages AFAIK. > > Have you seen an existing library that solves this problem is some > reasonable way? > Do you have other ideas or suggestions for how to design such API? > > -- > Maciej Sobczak *www.msobczak.com*www.inspirel.com > > Database Access Library for Ada:www.inspirel.com/soci-ada