1
OK, this is the third iteration, it has to be done right this time! :)
3
There are multiple tasks involved:
4
. Generating the header files (solved)
5
. Generating the memory allocators and typecodes (solved)
6
. Generating the POA tie-ins (solved)
7
. Generating the stubs and exception demarshallers (not so solved)
8
. Generating the skeletons and exception marshallers (not so solved)
10
So it is mostly doing the marshalling/demarshalling that is the hard part. The reason it is hard is because:
11
. We need to allow choosing between multiple mechanisms, e.g.:
13
Call to a separate function (possibly shared between multiple stubs/skels).
14
Use the CORBA_any routine.
16
It will not be an all-or-nothing decision between the mechanisms - we
17
will try to mix the different mechanisms according to heuristics. The
18
granularity of the decision will be on the level of a 'marshallable
19
entity' (big long words to denote something that can be marshalled,
20
hereafter abbreviated as 'ME').
24
def atomically_marshallable():
25
# The results of this function depend on more than just the data type, but also:
26
# Whether we have to do endian swapping (only applies to demarshalling)
27
# Whether the data arrangement in memory matches the data arrangement on the wire
30
if is_struct or is_union or is_sequence or is_array:
34
if atomically_marshallable():
36
else if not is_recursive() and data_type_use_count == 1:
39
if use_any_marshaller():
40
marshal_via_any_marshaller()
42
generate_marshalling_function()
43
call_marshalling_function()
45
The decision is made on a per-data-type basis and NOT on a per-stub
46
basis, because we want to be consistent (i.e. no inlining the
47
marshalling in one function and then calling the any_marshaller in
48
another function, for the same data type).
50
Generating the call-to-separate-function and ORBit_*marshal_any calls
51
should be easy once it is determined that this is desired. Generating
52
the inline code (and generating the separate-function, which will use
53
the 'inlined code' engine), is a difficult thing, because of the
54
optimizations involved and the different situations that the code
58
OK the above blah is either implemented or total crap.
60
Biggest issue that seems to be looming is memory management during
61
demarshalling. It's not at all clear whether caller or called
62
allocates, how we get rid of things if there is an error or we don't
66
Currently the marshal/demarshal code is stupid about
67
allocating, esp. for toplevels.
69
We need to handle all cases of OIDL_Marshal_Where properly.
71
OIDL_Marshal_Where is a function of context rather than data
72
type. It will always be MW_Heap or MW_Null for
73
stubs. We need the concept of 'allocation contexts' -
74
i.e. where a variable is 'auto' in or alloca'd in. No we
75
don't, we just need to have a mask of allowed marshalling
79
We need to know how to allocate a variable for each potential
80
OIDL_Marshal_Where and generate the valuestr for it.
82
'Caller allocates' allows some optimizations in
83
skeletons. So, if we are going to ask someone to demarshal
84
something, we need to make sure it is allocated first.
added
removed
docs/internals/idl-compiler.txt
