[OPEN-ILS-DEV] PATCH: transport_client.[ch] (tidying-up, and suggestions for more)

[Scott McKellar]

This patch tidies up a few things:

1. Corrected a few minor typos in the header.

2. Made the client_message_handler function static, since no other source
   file references it by name.

3. Moved several things from the header to the implementation file, of
   which all are internal details not referenced elsewhere:

-- The macros MESSAGE_LIST_HEAD and MESSAGE_LIST_ITEM
-- The declaration for struct message_list_struct, along with the
   associated typedefs

--------------------

I'm inclined to make more extensive changes, but I'd like to discuss
them first.

The point of transport_client is to provide a layer of buffering for
incoming transport_messages, my maintaining a queue of messages that
have already been received by the transport session.  However the
queuing machinery is not as sleek as it could be.

1. For each enqueued message we allocate a separate structure to hold
a pointer to the message and a pointer to the next node.  That's an
extra malloc and free for each message.

2. The first node is a dummy node associated with no message.  That's
an extra malloc and free for each transport_client.  Dummy nodes can
be useful in a doubly linked list, because they eliminate the need to
give the first real node any special treatment (when deleting a node
from the middle, for example).  In our queue of transport_messages,
however, the dummy node does nothing but get in the way.

3. When we enqueue a new message, we find the tail of the queue by
traversing the list from the head.  For n messages, the time complexity
for building the queue is O(n-squared).

--------------

I propose the following changes:

1. Add a "next" pointer to the transport_message.  The code in 
transport_message.c will initialize it to NULL but otherwise ignore it.

2. Eliminate the dummy node.

3. In the transport_client, maintain two pointers: one to the head of 
the queue and one to the tail.  Then the time complexity of building a
queue with n nodes will be O(n).

The last proposal is independent of the other two.  It will make a
difference only for longish queues.  I have no idea how long the queues
typically get, but I'm inclined to code for long queues.  Short queues
will be fast enough no matter how you manage them.

Give me the go-ahead and I shall prepare the patches accordingly.

Scott McKellar
http://home.swbell.net/mck9/ct/

Developer's Certificate of Origin 1.1 By making a contribution to
this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license indicated
in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source license
and I have the right under that license to submit that work with
modifications, whether created in whole or in part by me, under the
same open source license (unless I am permitted to submit under a
different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person
who certified (a), (b) or (c) and I have not modified it; and

(d) In the case of each of (a), (b), or (c), I understand and agree
that this project and the contribution are public and that a record
of the contribution (including all personal information I submit
with it, including my sign-off) is maintained indefinitely and may
be redistributed consistent with this project or the open source
license indicated in the file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transport_client_h_2.patch
Type: text/x-patch
Size: 4817 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20081206/257cca81/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transport_client_c_3.patch
Type: text/x-patch
Size: 1796 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20081206/257cca81/attachment-0001.bin