[interfacekit] Re: Portlink implementation

On Mon, 21 Oct 2002 21:23:56 +0300 "Adi Oanca" <adioanca@xxxxxxxxxxxxx>
 wrote:
> [ this one might be a duplicate, but the first one seems not to have 
> reached
> the list]
> 
> > Looking through Portlink source code, I saw it does (too) many 
> > copies of
> the data (IMHO).
> > For example, every time you add a byte/int/whatever, it creates a
> PortlinkData object, it copies the data there, then adds that object 
> to a
> BList (which could involve a reallocation of the BList's buffer). 
> When you
> flush the data, the BList content is copied in a plain buffer (which 
> is
> allocated/deallocated every time), then the content of that buffer is
> written to a port (I guess it involves another copy). I think this is 
> just
> overkill.
> >
> > Couldn't we just use a fixed buffer for portlink, and put the data
> directly there?
> > For example (note that there's no error checking here):
> >
> > Attach(const void *data, size_t size)
> > {
> >   memcpy(data, fBuffer + fSize, size);
> >   fSize += size;
> > }
> >
> >
> > where fBuffer could be an array of 1024 bytes (a reasonable value, 
> > I don't
> think we are going to write that much data at a time on a port)
> >
> > and then:
> >
> > Flush()
> > {
> >   write_port(fTarget, fOpcode, fBuffer, fSize);
> >   fPos = 0;
> > }
> >
> > It would be much simpler, much cleaner, and much faster.
> > Just an idea. Comments are welcome :P
> 
> OK, then...
> 
> > Couldn't we just use a fixed buffer for portlink, and put the data
> directly there?
> 
>     My answer would be NO. Why??? PortLink is by... "use" conception,
> different from _BSession_.
>     In PortLink architecture(witch I think is better than _BSession_) 
> a
> hole(big) message can be cached before sending it to... app_server.
>     With _BSession_ this isn't so... natural, and not as... "good" I 
> might
> say.
> Once a
> message is more than 1024 bytes long... the app_server will have to 
> WAIT for
> the rest of the message, a thing, I find quite dangerous, if our 
> application
> crashes during that time; this would go in an confusion in one thread 
> in
> app_server and, the results in that window would be NULL.
>     With PortLink... all things are beautiful, every command is 
> cached, and
> every command is *complete* when it reaches the app_server.
> 
>     Indeed PortLink does TOO many allocations, this should be 
> fixed!!! But,
> if we'll adopt your solution, MANY MANY changes should be made! Note 
> here,
> that PortLink is different is conception than _BSession_- that's why!
> I was
> planning to talk very soon this with DW, and I also had a solution. 
> It goes
> something like this:
> 
> * a simple linked list of the following structure
> struct _BPage_{
>     uint8    *ptrLocationOfAllocatedBuffer ( = new uint8[1024]);
>     uint8    noOfBytesInBuffer
> }
> 
> - when our message is bigger than 1024 bytes, we should allocate a 
> new
> _BPage_ add it to the list and write data into it just like you
> said(directly).
> 
> Then when Flush(), we'll alocate a new buffer witch is equal with our
> message size, copy all the data from _BPage_s into it and sent it to
> app_server.

While that sounds OK, I would still vote for using BMallocIO. It would 
require less coding and I don't see significant drawbacks in 
comparisson with your idea.

> > Just an idea. Comments are welcome :P
> 
>     Likewise :P
> 
> BTW: Ingo! You said you'll supply us with a small library for using
> simple/double liked lists, hash tables,... whre is it? :)

More correctly Tyler and I wanted to implement such a library. :-)
It's beginnings are in `headers/private/kernel/util'. I only now and 
then added bits I needed and Tyler currently doesn't have time for it, 
so there are only few classes at this time. Basically only 
SinglyLinkedList, Vector, and Vector{Set,Map}. For the AVLTreeMap I 
currently see no chance to get it past our buggy compiler. Also the 
interfaces are not completely stable, so if you want to use any of the 
classes, keep that in mind.

CU, Ingo

Other related posts: