Tasks

Headers:
Typedefs

Prototypes (per-interface, per-operation, per-type).

Common:
Allocation & freeing (per-type).

Stubs:
Stubs (per-operation)
Short-circuiting
Setup
Marshalling
Exception & location_forward handling
Sending
Receiving
Freeing/allocating values
Demarshalling
Return

Skeletons:
Skeletons (per-operation)
Allocating values
Demarshalling
Call
Setup for reply
Exception handling
Marshalling
Sending
Freeing values
Return


(de)marshalling tasks

All (de)marshalling tasks can be represented using the following type of data
structure (PIDL):
union MarshalNode switch(NodeType) {
case VALUE: {
string variable_name;
short value_length;
}
case CONSTANT: {
long value;
}
case ARRAY: {
string pointer_name;
MarshalNode num_entries;
}

IDL_tree corresponding_idl_node;
};

Need to make a data structure that better represents "what we need to do"
rather than "what we are working on". Something that can say "(de)marshal
value|increment a pointer|loop back"... Optimization on this will be somewhat
easier.

/* In skels: If not sending a reply back, don't get a send_buffer
unless we need to raise an exception. */ Incorrect - for any given op
you either always need to send something back, or never.

Pieces of a stub (prerequisite steps are in []'s):
Pre:If ev == NULL, bomb out.
1.Sanity check params (and handle exceptions).
2.Check for & handle local call. [1]
3.Get connection (and handle exceptions). [1]
4.Get send buffer (is it possible for any exceptions to be raised here?).
5.Marshal params. [1, 4]
6.Write send buffer (and handle exceptions). [5]
7.Unuse send buffer. [6]
8.Receive reply (and handle exceptions). [6]
9.Do any necessary location forwarding & exception handling. [8]
10.Allocate any needed memory for retvals.
11.Demarshal retvals (with versions for endianness) (and handle exceptions). [9, 10]
12.Unuse receive buffer. [11]
13.Return. [11]

Could swap 2 & 3, or 7 & 8. 11 & 12 can't be swapped due to 12's flow
changing effects :-). Don't want to swap 2 & 3 - don't do remote stuff
it is local. 7 & 8 just maybe could be swapped, but not sure it makes much sense.

Pieces of a skeleton (prerequisite steps are in []'s):
0.      Allocate any needed memory for params.
1.Demarshal (with versions for endianness) (and handle exceptions). [0]
2.Call impl. [1]
3.Get send reply buffer (can this raise any exceptions?). [2]
4.If no exceptions raised:
Marshal retvals. [3]
else marshal exceptions. [3]
5.Write send buffer (and handle exceptions). [4]
6.Unuse send buffer.

No pipelining possible in skeletons.

Actually, should integrate memory allocation with demarshalling - it'd
be cleaner to do (if not a little more space wasting when it comes to
dual versions for endianness).

You can marshal multi-element pieces of structs.

In skels: If not sending a reply back, don't get a send_buffer unless
we need to raise an exception.

When demarshalling, maintain a local 'cur' pointer rather than modifying
the one inside the receive buffer. Will need to update the one inside the
rbuf if we call a complex demarshaller thing.

Reduce amount of code in stubs by having send_buffer_use() return the
request_id as part of its operation, instead of having to get a new
request_id as part of the stub.

Use function pointers instead of a series of if's to speed things up.

Pre-computation of alignment for stuff that can be pre-computed (like
operation name vecs, etc.)

For multithreading speedups, don't lock the connection until we actually need to send.