[interfacekit] Re: Portlink implementation

> > 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.

Why would you cache the complete message, it's an instruction stream, and
the sooner the app_server gets a piece, the sooner it can start rendering.

> Once a
> message is more than 1024 bytes long... the app_server will have
> to WAIT for
> the rest of the message,

Yup, it will have to wait, but as I told you in a private mail, it doesn't
have to wait long. The buffer is flushed everytime an instruction is sent
which requires a reply, like B_GET_HIGH_COLOR or B_SYNC. The buffer is also
flushed in the task_looper loop, which is everytime you give control back to
the message loop.

> 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.

If the app crashes during this time nothing wrong happens on the app_server.
The server window will just keep waiting on the port_read, and ?picasso?
will clean up the resources the app used on the app_server.

>     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!

What changes exactly?

> 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).

If you're really against a fixed buffer (which is proven to work perfectly
in BeOS), I would at least use realloc.

> 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.

This is what we want to prevent, _BSession_ is extremely fast because it
doesn't need allocations/deallocations and only does one copy to put the
data into the buffer. We need to be able to send what we have in the buffer,
not copy it again. Besides there's a limit to port capacity, you can't just
send a message of any size.

Marc Flerackers

Other related posts: