1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HEAD>
<TITLE>TAO TO-DO List</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<!-- $Id$ -->
<CENTER><HR></CENTER>
<CENTER>
<H3>General TO-DO list for TAO</H3>
</CENTER>
<P>
This document presents our TO-DO list for TAO.
Currently, the list is not very well organized or prioritized.
It started as a personal TODO list for Carlos, so it is biased
towards the Event Service and related components.
As more people get involved it will become more
organized.
</P>
<P>
Last Updated: $Date$ $Revision$
</P>
<HR>
<P>
<H3>Work in progress</H3>
</P>
<OL>
<LI><P>Implement an Implementation Repository for TAO.
<BR>[ASSIGNED TO:] Darrell.
</P>
</LI>
<LI><P>Support the thread pool reactor in the ORB.
<BR>[ASSIGNED TO:] Nanbor.
</P>
</LI>
<LI><P>Add support for multiple Profiles in the ORB (completing
the IIOP 1.0 support)
<BR>[ASSIGNED TO:] Fred
</P>
</LI>
<LI><P>Implement a nice example of the COS Event Channel,
showing how it can provide filtering when combined with the
real-time Event Channel.
<BR>[ASSIGNED TO:] Pradeep
</P>
</LI>
<LI><P><B>EC:</B> The current architecture of the real-time
Event Channel does not support some features, such as:
<UL>
<LI><P><B>EC:</B> Some applications are both suppliers and
consumers of events,
they may be interested in all the
events of type <B>T</B> unless the event is generated
by them.
</LI>
<LI><P><B>EC:</B> Can we factor out the scheduling service from
the EC?
</P>
</LI>
<LI><P><B>EC:</B> The reactive event channel can eliminate
data copies because the data does not need to survive
after the <CODE>push()</CODE> call.
</P>
</LI>
<LI><P><B>EC:</B> Many applications require to intercept
the EC event processing, for example to keep track of
the number of events received and sent.
This requires strategized factories for many (if not
all) of the Event Channel internal servants.
</P>
</LI>
<LI><P><B>EC:</B> Some applications require ad-hoc
filters, such as "this events must arrive in
sequence", or "wait for all this events and then send
this other event".
</P>
</LI>
<!-- This is Boeing specific -->
<LI><P><B>EC:</B> For some applications it is insteresting
to activate the EC servants (such as the
ConsumerProxys) in different POAs
</P>
</LI>
</UL>
We have completed a new design for the real-time event
channel that will let us implement all this features (and
others).
<BR>[ASSIGNED TO:] Carlos
</P>
</LI>
</OL>
<HR>
<P>
<H3>Pending Tasks</H3>
</P>
<H4>Performance optimizations</H4>
<OL>
<LI><P>Location forwarding should be strategized since some
applications don't need this feature.
</P>
</LI>
<LI>Further optimize the outgoing memory allocation by adding
support for message blocks allocated from a pool (the
Message_Block class itself not the Data_Block or the buffer it
contains).
<P></LI>
<LI>Optimize twoways by delaying memory allocation for the
incoming data buffer, thus improving interleaving between the
client and server (the client does something useful before
starting to wait for the server).
<P></LI>
<LI>The data blocks and their buffers could be allocated in a
single operation, using the beginning of a buffer to contain
the data block and the rest of it to contain the actual buffer
<P></LI>
<LI><P>Some applications cannot afford compiled marshaling for
all the stubs and skeletons,
the generated code size would be too big.
Yet some operations could be critical and require code as
efficient as possible;
a <CODE>#pragma</CODE> can be added to give users
fine-grained control over code generation.
</P>
</LI>
<LI><P>For extremely low latency applications we could remove
some fields from the IIOP protocol, for instance:
<UL>
<LI>The first four bytes are always 'GIOP'
</LI>
<LI>In homogeneous environments sending the byte order is a
waste
</LI>
<LI>Fields like the <CODE>Principal</CODE>, the services
context list, the versions can also be removed
</LI>
</UL>
<BR>[STATUS] Most of this optimizations were implemented,
and can be enabled using the <CODE>-ORBiioplite</CODE> command
line option.
</P>
</LI>
<LI><P>Once the memory for incoming data is taken from an
allocator we can implement different approaches to manage
that memory:
<UL>
<LI>The allocator is global, allowing applications to keep
the incoming buffer even after the upcall has finished.
</LI>
<LI>The allocator is TSS, giving maximum performance for
applications that do not wish to preserve the buffer
after the upcall.
</LI>
<LI>The allocator is a TSS cache for a global memory pool,
this tries to strike a balance, by practically eliminating
the locking on each allocator/deallocation. Some strategy
is required to return the memory to the global pool,
consider, for example,
an application that will always allocate memory from one
thread and deallocate it in another thread.
</LI>
</UL>
</P>
</LI>
<LI><P>Optimize marshaling for <CODE>TypeCode</CODE>, by not
including the optional fields on the wire;
this fields are useful (in some cases), so they should be
present for the "on memory" representation.
</P>
</LI>
<LI><P>In some cases it is possible to marshal a complete
structure in a single operation to allow this the structure
must have fixed size (in the CDR spec sense) and its memory
layout must match the CDR layout.
</P>
</LI>
<LI><P>If all the arguments to an operation are fixed size then
the header can be sent before the rest of the data, if the
data is big enoug this can represent a performance
improvement (because we increase overlapping between client
and server); further if the arguments also have the proper
layout they can be sent without copying to a temporary
buffer.
</P>
<P>If the arguments are not fixed size the header could be
sent before, but two passes over the data will be required.
</P>
</LI>
<LI><P>One GIOP 1.1 is implemented we could use fragments to
minimize the buffer allocations:
the buffer could be fixed size and we simply send fragments
for each buffer.
</P>
</LI>
<LI><P>Demarshaling and managment of Anys could be optimized,
they esentially keep a copy of the CDR stream,
but they could just keep a reference (and increase the
reference count).
</P>
</LI>
<LI><P>Some uses of DSI can optimized also,
for instance,
if the application is simply going to forward the request to
another object there is no need to parse the arguments in
the CDR stream and decompose them in the arguments,
a single *big* CDR stream can be kept.
</P>
</LI>
<LI><P>In the collocated case the generated
<CODE>_narrow()</CODE> method calls the
<CODE>_create_stub()</CODE> method that allocates several
temporary objects.
</P>
</LI>
<LI><P>For various projects, we need to produce a
minimal-footprint TAO ORB. One thing we could probably do
very easily would be to provide an #ifdef that will
conditionally omit the servant manager, POA manager, and
adapter activator features from TAO, along with all the
demuxing features that aren't active demuxing or perfect
hashing.
</P>
</LI>
<LI><P>The CDR streaming classes compute the alignment on each
operation, but they could remember the alingment from the
previous insertion or extraction operation; saving a few
cycles but spending a little more memory.
</P>
</LI>
</OL>
<H4>New features and Bug fixes</H4>
<OL>
<LI><P><B>EC:</B>Sometimes the Event Channel dead-locks during
shutdown. According to Ulf Jährig <jaehrig@desys.com>>;, an
easy way to reproduce the problem is to run the
EC_Throughput test under windows NT.
</P>
</LI>
<LI><P>Support native C++ exceptions.
This entails the following subtasks:<P>
<OL>
<LI>Create exceptions with the right dynamic type on the
client side.
For SII this should be simple:
the stub give us a list of the
possible user exceptions together with the factory methods
to allocate an exception of each type;
if the exception is not on that list we throw a
<CODE>CORBA::UNKNOWN</CODE>.
For DII we have to throw a
<CODE>CORBA::UnknownUserException</CODE>;
the user will receive the real exception inside an
<CODE>Any</CODE> then and she will have to extract it
either using the >>= operator or using the
forthcoming <CODE>DynAny</CODE>.
System exceptions are even easier, we always know how
to create them.
<BR>[STATUS] SII is working OK, we still need to complete
the support for DII.
<BR>[STATUS] The DII support was completed, but remains
untested.
<P></LI>
<LI>Add the _raise() method to the exceptions.
<BR>[DONE]
<P></LI>
<LI>On the server side: catch any CORBA exceptions thrown by
the upcall, and then transform that into the
proper <CODE>Reply</CODE> to the client side.
In the case of another C++ exception should we do
something?
<BR>[DONE]
<P></LI>
<LI>On the client side, after creating the exception with
the right dynamic type we must invoke
<CODE>_raise()</CODE> on it.
<BR>[DONE]
<P></LI>
<LI>Provide a TSS default value for the CORBA_Environment,
all the methods in the ORB library should use this
default.
<BR>[DONE]
<P></LI>
<LI><B>IDL Compiler:</B>The IDL compiler should be able to
generate the
alternative mapping, but with the TSS default for the env
argument.
<BR>[DONE]
<P></LI>
<LI><B>IDL Compiler:</B>The IDL compiler should generate the
standard mapping, without the environment argument.
<P></LI>
<LI>In general we will need to complete and debug the
<CODE>TAO_TRY</CODE> macros;
they have limitations when dealing with the
alternative mapping, but are very useful.
<BR>[STATUS] This seems to be OK now, the code seems to
compile and work correctly now.
<BR>[STATUS] We need a new macro (TAO_TRY_THROW) to use
inside the TAO_TRY blocks, because TAO_THROW will not go
into the TAO_CATCH blocks, even if the exceptions match.
<P></LI>
<LI>We need to test the ORB for resource leaking in the
presence of exceptions.
<P></LI>
<LI>We <EM>could</EM> write portable server side code with
any of the mappings above if we use a macro for the env
argument, but the results are ugly:
<PRE>
// IDL
interface Foo {
void bar (in long x);
};
// C++
class Foo {
void bar (CORBA::Long x TAO_ENV_ARG)
TAO_THROW_SPEC ((CORBA::SystemException));
};
</PRE>
note the missing comma before the TAO_ENV_ARG parameter.
<P>
</P> A different alternative is to generate both
functions, and make the default implementation just invoke
the other:
<PRE>
// IDL
interface Foo {
void bar (in long x);
};
// C++
class POA_Foo {
void bar (CORBA::Long x, CORBA::Environment& env)
TAO_THROW_SPEC ((CORBA::SystemException))
{
this->bar (x);
}
void bar (CORBA::Long x)
TAO_THROW_SPEC ((CORBA::SystemException)) = 0;
};
</PRE>
The problem is: which alternative should be the pure
virtual function? Which one is overriden by the user?
<P></LI>
</OL>
<BR>[STATUS] The main task ahead is to generate the conforming
mapping for the server side, i.e. remove the
<CODE>CORBA::Environment</CODE> argument and generate the
throw specs.
We need to wait for the compiled marshaling support to
implement this feature, otherwise the number of conflicts,
visitors and factories will grow without limit.
</P>
</LI>
<LI><P><B>EC:</B> Automate EC multicast group usage. This probably
requires some kind of server that mantains the relation
between event type/source and the mcast groups.
<BR>[STATUS] The multicast map server was defined, an
example implementation that hardcodes the port, and casts
the event type into the mcast address was implemented.
<BR>[STATUS] An advanced example that uses multiple mcast
groups per process was developed; this example would be used
To test the required features for general mcast support.
<BR>[STATUS] The example is able to automatically join and
leave multicast groups, as the consumer set on a local EC
changes.
The test has been constructed to minimize resources, it only
uses one socket for outgoing multicast messages;
currently it uses only one socket for each local group of
multicast UDP addresses sharing the same port;
eventually more sockets may be needed,
as sockets have limits on the number of multicast groups
they can join.
</P>
</LI>
<LI><P><B>EC:</B>The <CODE>TAO_EC_Gateway_IIOP</CODE> can be
required to subscribe for events by source, but the source
can be local instead of remote.
This is not a problem since the Event Channel supports
multiple supplier IDs,
but we could check the local publications and remove those
events from the Gateway publication and subscription list.
</P>
</LI>
<LI>Support IIOP 1.1 in the ORB
<P></LI>
<LI>Use the IIOP 1.1 profile info to pass QoS info and use it to
preserve end-to-end QoS.
<P></LI>
<LI>Support IIOP 1.2 in the ORB
<P></LI>
<LI>Support GIOP 1.1 in the ORB (fragments)
<P></LI>
<LI>The size of pre-allocated buffer for the outgoing CDR
streams is defined at compilation time; but if we use an
efficient enough allocator we could make its size configurable
via the svc.conf file. In any case the *second* (and
subsequent) buffers come out of the allocator, so their sizes
could be configured in the already mentioned file.
<BR>[NOTE] We have to be able to do this while minimizing the
number of calls to ORB_Core_instance()
<P></LI>
<LI><B>IDL Compiler:</B> The IDL compiler front-end should be
case insensitive,
more precisely it should flag identifiers that only differ by
case as a conflict and verify that all uses of an identifier
have the same case.
<P></LI>
<LI><B>IDL Compiler:</B> The operation tables do not need to be
statics, they could be created on creation of the first
servant of that type.
<P></LI>
<LI><B>IDL Compiler:</B>Support for unions with default cases
(implicit or explicit)
in the IDL compiler is incomplete.
<P></LI>
<LI>It seems that some memory is leaked from the ORB cached
connector.
<P></LI>
<LI><B>IDL Compiler:</B>Support for the <CODE>fixed</CODE> data
type in the IDL compiler
<P></LI>
<LI>CDR stream support for <CODE>wchar</CODE> is flaky or at
least untested.
<P></LI>
<LI>Add a <CODE>corbafwd.h</CODE> header file to eliminate the
deep (and recursive) header dependencies in TAO.
<P></LI>
<LI>Add << and >> operators to the
<CODE>CORBA::Request</CODE> class, to simplify DII invocations
(this is an Orbix-sism).
The IDL compiler has to generate them for the user defined
types.
<P></LI>
<LI>Several helper structs for <CODE>Any</CODE> have to be
added, mainly: <CODE>to_object</CODE>, <CODE>to_wchar</CODE>,
<CODE>to_wstring</CODE> and their <CODE>from_</CODE>
<BR>[STATUS] Jeff added several of them, I need to check what
is missing.
<P></LI>
<LI><P><B>IDL Compiler:</B>The IDL compiler could generate files
with empty
implementation classes, just to make the life of implementors
a bit easier.
</P>
</LI>
<LI>Prepare the 1.0 release:<P>
<OL>
<LI>Integrate the compiled marshalling approach.
<BR>[STATUS] Andy has made great progress on this.
</LI>
<LI>Verify the GPERF is working in all the relevant
platforms.
<BR>[STATUS] As far as we know it is working correctly.
</LI>
<LI>Integrate active demux of operations?
</LI>
</OL>
<P></LI>
<LI>Support the Sun bootstrapping mechanism for the Naming
Service
<P></LI>
<LI>Add a -ORBlogfile flag so we can set the ACE_ERROR and
ACE_DEBUG output destination in all TAO applications
<P></LI>
<LI>Support several calls to ORB_init() on the same thread.
<P></LI>
<LI><B>EC:</B> Call ORB_init() in the EC threads?
[The dispatching threads for Boeing]
<P></LI>
<LI><B>EC:</B> Build an EC example that uses all the cool features
(multiple ORBs on each process, collocated EC and Scheduling
service, Naming, etc.)
<P></LI>
<LI><B>EC:</B> Extend the Concurrency Service (or create a new
one) that allow us to have global "barriers" to synchronize EC
startup/shutdown.
<P></LI>
<LI><B>EC:</B> Debug interval computation in Linux (and NT?)
<P></LI>
<LI><P>Remove the uneeded methods from CORBA::Object
<BR>[STATUS] This task seems to be complete
</P>
</LI>
<LI><B>IDL Compiler:</B> The IDL compiler could generate a static
method to access the interface repository ID of a class.
<P></LI>
<LI><B>IDL Compiler:</B> The IDL compiler should support
<CODE>#include "orb.idl"</CODE> properly.
IMHO it should not
add any <CODE>#include</CODE> to the generated code and the
<CODE>orb.idl</CODE> file should contain all the declarations,
except for the pseudo objects that are should be hardcoded
into the compiler.
<P></LI>
<LI>The current scheme for the orbsvcs leaves the user without
control over collocation of servants, we need to move to a scheme
similar to the one in $ACE_ROOT/netsvcs.
<BR>[STATUS] The user can control collocation, but we need a
dynamic way to do it (or an example) that exploits the Service
Configurator. We also may need to split the library.
<P></LI>
<LI><B>EC:</B> Use the Service_Configurator to dynamically load
the EC Module_Factory thus making it really configurable.
<P></LI>
<LI><B>EC:</B> Cleanup the IDL structures for subscriptions,
publications, etc. (in the EC).
<BR>[STATUS] Part of this was completed. The Header and
Payload of the events are clearly distinguished, now we need
to use only the Header in the Publication and Subscription
definitions.
<P></LI>
<LI>Resolve the <CODE>Typecode::equal</CODE> dilemma: is it
structural or type equivalence? Or a mixin?
<BR>[STATUS] The correct interpretation seems to be:
<UL>
<LI>If the interface repository ID is not present and/or the
optional field name is not present then TypeCode::equal
should just test for structural equivalence.
<P></LI>
<LI>If the interface repository ID is present then type
structural equivalence is not enough
<P></LI>
<LI>The spec (2.2 or 2.3?) will add a
<CODE>equivalent</CODE> method to check for structural
equivalence modulo aliases
<P></LI>
</UL>
<P></LI>
<LI><P><B>IDL Compiler:</B> The methods on the server side
<B>must</B> have a throw spec, check CORBA 2.2, 20.35
</P>
</LI>
<LI><P>According to Vinoski and Henning the
<CODE>CORBA::Policy</CODE> objects are also locality
constrained.
I could not find a references in the spec.</P>
</LI>
<LI><P>Exercise the insertion and extraction operators for
<CODE>Any</CODE> in the <CODE>Param_Test</CODE>,
for example, provide a new <CODE>-i dii_any_op</CODE>
testing mode.
</P>
</LI>
<LI><P>Test Any with variable sized types, such as structures
that contain a string inside. Jeff reports that there is a
problem when destroying Anys initialized with this types,
even if the IDL compiler generated <<= operator is used.
</P>
</LI>
<LI><P>Include a regression test to verify that
<CODE>octet</CODE> is <B>not</B> a valid discriminator for
unions
</P>
</LI>
<LI><P><B>IDL Compiler:</B> CORBA 2.2 does not allow
<CODE>octets</CODE> as
constants, yet the IDL compiler does not complain about it.
</P>
</LI>
<LI><P>Verify that the typecode for unions use a
<CODE>octet</CODE> with value <CODE>0</CODE> for the default
discriminator
</P>
</LI>
<LI><P>Is the client side in TAO handling a
<CODE>CloseConnection</CODE> GIOP message properly?
</P>
</LI>
<LI><P>If the connection to the server cannot be established the
right exception is <CODE>TRANSIENT</CODE>, not
<CODE>COMM_FAILURE</CODE>; this and other exception
inconsistencies have to be checked
</P>
</LI>
<LI><P>The spec (CORBA 2.2, 20.17) defines accesor methods for the
fields of a <CODE>SystemException</CODE>.
</P>
</LI>
<LI><P>In some platforms it may be necessary to add an extra
value to an enum to force it to be 32-bits wide.
</P>
</LI>
<LI><P>The spec requires that strings as fields of structures be
initialized to the empty (not the null) string.
</P>
</LI>
<LI><P>The <CODE>SINGLE_THREAD_MODEL</CODE> for the POA requires
that the execution for all request on that POA happen on the
same thread.
</P>
</LI>
<LI><P><CODE>$TAO_ROOT/orbsvcs/tests</CODE> may require the same
hierarchy changes that were done in
<CODE>$TAO_ROOT/tests</CODE>.
</P>
</LI>
<LI><P>The <CODE>_duplicate()</CODE> and <CODE>_narrow()</CODE>
functions can throw exceptions, yet our mapping does not
contain an <CODE>CORBA::Environment</CODE> argument.
A similar problem ocurs with
<CODE>ORB::resolve_initial_references</CODE>, the ORB can
throw the <CODE>InvalidName</CODE> exception.
</P>
</LI>
<LI><P>Apparently the implementation for the leader-follower
model on the client side has bug:
it will add the current thread to the follower list every
time it returns from waiting in the condition variable,
assuming that it was signaled and removed every time.
</P>
</LI>
<LI><P>By default TAO disables Nagle's algorithm, this should be
an optional feature, otherwise TAO will perform poorly over
WANs.
</P>
</LI>
<LI><P>Improve the connection recycling strategies, for
instance,
several strategies are possible: limit the maximum number of
open sockets, probably with both HWM and LWM bounds,
with different policies to choose the socket to close (LFU,
MRU?);
or maybe be more aggresive and recycle a socket once
all the object references pointing to a server are closed.
The later approach could be easily implemented if each
IIOP_Object held a reference to the set of sockets opened to
a certain TCP/IP address.
</P>
</LI>
<LI><P>Check that system calls like <CODE>recv()</CODE> and
<CODE>send()</CODE> are restarted if a signal is received by
the process while they are executing.
</P>
</LI>
<LI><P>Update the collocated test in Cubit
</P>
</LI>
<LI><P><B>IDL Compiler:</B> The CORBA 2.3 spec clarifies the scope of a
<CODE>#pragma prefix</CODE>:
the prefix is supposed to get cleared after each
<CODE>#include</CODE>,
also the statement
<PRE>
#pragma prefix ""
</PRE>
should clear the prefix.
</P>
</LI>
<LI><P><B>IDL Compiler:</B> GPERF is generating a function for
each binary search table;
a generic function could be used, or at least we should add
an option to gperf to it receives that generic function as
an argument.
</P>
</LI>
<LI><P><B>IDL Compiler:</B> The TAO_IDL compiler does not handle
the following code sequence properly:
<PRE>
// IDL
interface Foo;
typedef sequence<Foo> FooSeq;
interface Foo {
// anything here
};
</PRE>
It may be necessary to have a multi-pass code generator to
solve this problem.
</P>
</LI>
<LI><P><B>IDL Compiler:</B> Tom Ziomek
<tomz@cc.comm.mot.com> reports that the IDL
compiler does not verify that <CODE>oneway</CODE> operations
cannot include a <CODE>raise</CODE> expression.
</P>
</LI>
<LI><P><B>IDL Compiler:</B> We must also check that oneways do
not contain any <CODE>out</CODE> or <CODE>inout</CODE>
parameters.
</P>
</LI>
<LI><P>Currently we use blocking writes for the request, we need
to change this so we use the Reactor to send the data
instead of blocking directly on the <CODE>writev</CODE> call.
</P>
</LI>
<HR>
<!-- Things below this point are "big" tasks" that -->
<!-- could require major work -->
<LI><P>Provide mechanisms to marshal arguments into a CDR
stream, Jon Biggar contributed his proposal to the CORBA 2.3
RTF:
<PRE>
Issue 991: Operations to add to CORBA::ORB pseudo-object
Proposal:
[Note I have expanded the SerializedEncoding IDL type to include version
information, since we now have 3 versions of CDR!]
The following operations should be added to the CORBA::ORB
pseudo-object:
module CORBA {
interface ORB {
...
typedef sequence<octet> SerializedData;
typedef unsigned long SerializedFormat;
const SerializedFormat ENCODING_CDR = 0;
struct SerializedEncoding {
SerializedFormat format;
octet major_version;
octet minor_version;
};
SerializedData serialize(in Any data,
in SerializedEncoding how);
Any unserialize(in SerializedData data,
in SerializedEncoding how);
SerializedData serialize_value(in Any data,
in SerializedEncoding how);
Any unserialize_value(in SerializedData data,
in SerializedEncoding how,
in TypeCode tc);
...
};
};
These operations provide a standard mechanism for serializing and
unserializing the data in an any, along with hooks to support new
encoding formats as they are needed. The type SerializedEncoding
indicates the encoding mechanism to use to serialize and unserialize the
data. The format field specifies what encoding rules to use when
serializing the data, and the major_version and minor_version indicate
what version of the encoding rules to use.
The serialize and unserialize encode the TypeCode along with the value
so that the serialized data is self contained. The serialize_value and
unserialize_value version encodes the value without the TypeCode to save
space, but a TypeCode must be supplied to unserialize the data.
Since the serialized data may contain no indication of machine dependent
issues such as byte order, the serialized data can only be guaranteed to
correctly be unserialized on the same ORB. The IDL any type should be
used to exchange information between ORBs.
Data encoded using the ENCODING_CDR format will be encoded using CDR
encapsulation format.
</PRE>
</P>
</LI>
<LI><P>Add support for Smart Proxies to the ORB</P>
</LI>
<LI><P>The ORB should support server side and client side
interceptors</P>
</LI>
<LI><P>The ORB does not have an interface repository</P>
</LI>
<LI><P>Once the interface repository is in place we could add
support for CORBA script
</P>
</LI>
<LI>The current scheme for Typecode (keeping a CDR buffer with
their representation) is broken; we should use classes for
each variant of a TypeCode; but initialization would be
complicated then.
<P></LI>
<LI><P>The CORBAlite RFP is very interesting IMHO we just need to
remove features from TAO to make it a CORBAlite
implementation. The problem is how to keep the full blown
CORBA implementation also, this is an idea:
Write the TAOlite version of a class (example TypeCode):</P>
<PRE>
class TAO_CORBAlite_TypeCode {
// Just the CORBAlite methods are implemented.
};
</PRE>
<P>Derive the full blown implementation:</P>
<PRE>
class TAO_CORBA_TypeCode : public TAO_CORBAlite_TypeCode {
// Declare all the other methods.
};
</PRE>
<P>create two namespaces:</P>
<PRE>
// in tao/CORBAlite.h
class CORBA {
tyedef TAO_CORBAlite_TypeCode TypeCode;
};
// in tao/CORBAfull.h
class CORBA {
typedef TAO_CORBAfull_TypeCode TypeCode;
};
</PRE>
<P>then (at compile time) the users chooses between the CORBAlite
or CORBAfull implementations:</P>
<PRE>
// In $TAO_ROOT/tao/corba.h
#if USERS_WANTS_FAT_FREE_CORBA
#include "tao/CORBAlite.h"
#else
#include "tao/CORBAfull.h"
#endif
</PRE>
<P>We need to consider how to support even smaller profiles that
the CORBAlite RFP, like removing <CODE>Any</CODE> or
<CODE>fixed<></CODE> support.
We also need to come out with a scheme to support
interpretive marshalling in the CORBAlite framework (where
TypeCodes don't have enough methods as to traverse them).
</P>
<P>
</LI>
<LI><P>Consider decompositions of the ORB that would allow
dynamically linked plug-ins, for example it should be easy to
dynamically load a pluggable protocol.
Other decompositions are harder, but still worthwhile looking
at:
<UL>
<LI>Dynamically load the support for costly features, as the
ImplRepo or Location Forwarding.
<P>
</LI>
<LI>Dynamically configure POA with or without support for
holding state.
<P>
</LI>
</UL>
</P>
</LI>
<LI><P><B>IDL Compiler:</B> Currently the IDL compiler creates an
operation table that
includes all the base classes operations; this permits the
generation of efficient code that does not rely in
dynamic_cast or the _downcast() method for Servants (which
compare strings, hence it is slow).
It could be interesting to implement the alternative approach
were the class only looks its own operations and then tries
the parent. This will reduce code size, but will probably
decrease performance.
</P></LI>
<LI>Server_Request objects in TAO are magical, the _duplicate()
method returns 0 and release() does nothing.
The problem starts because Server_Request is allocated from the
stack (to speed up things), hence reference counting would be
useless. Adding a clone() method will work better, but the
Server_Request holds pointers to several positions in the CDR
stream, we could clone the CDR stream, but a normal
Server_Request does not own it.... In our opinion (Carlos and
Irfan) we need not worry about this until we find a use case for
it.
<P></LI>
<LI>
The current implementation of collocation is optimal for
hard-real-time
applications, but in some cases it may be desirable to follow
the normal execution path yet minize costs for collocated
calls.
An example would include an application that activates the
objects on demand.
It would be interesting to have a half-collocated stub
implementation, that will marshall the request and then
invokes the normal path on the "server" side, but without
crossing the kernel boundary. Ideally even the serialization
could be minimized or avoided.
<P></LI>
</OL>
<HR><P>
<H3>Completed Tasks</H3>
<OL>
<LI><P><B>EC:</B> Build a COS Event Channel on top of the RTEC
Event Service.
<BR>[ASSIGNED TO:] Pradeep
</P>
</LI>
<LI><P><B>EC:</B>Implement fragmentation and reassembly of UDP
messages. This is important for an effective implementation
of the multicast version of the EC. The classes affected
include <CODE>UDP_Receiver</CODE> and <CODE>UDP_Sender</CODE>.
<BR>[DONE]
</P>
</LI>
<LI><P><B>EC:</B> The Event Channel must be profiled,
quantified, etc.
Now that we have a single threaded event channel this task
is much easier, the points to investigate are:
</P>
<P>
<UL>
<LI> How many data copies does the EC make? Can we reduce it
to zero?
</LI>
<LI> How many memory allocations?
<BR>[RESULT: 8]
<BR>Can they be replaced by memory pools?
</LI>
<LI>How many locks?
<BR>[RESULT: 29 (single threaded), 31 MT]
<BR>Can we strategize locks?
<BR>Can we share a single lock for the whole dispatch?
</LI>
</UL>
<BR>[ASSIGNED TO:] Carlos
</P>
</LI>
<LI><P>The TypeCode internal (private) state needs locking, double
checked locking is needed to avoid excessive overhead, there
is potential for memory leaks if this locking is not used.
<BR>[DONE]
</P>
</LI>
<LI><P><B>EC:</B>The <CODE>UDP_Receiver</CODE> class has some
problems on Win32 platforms because a
<CODE>recvfrom()</CODE> call fails if the buffer is to small
for the datagram, even if the <CODE>MSG_PEEK</CODE> flag is
used. We may need to modify the
<CODE>ACE_OS::recvfrom()</CODE> call to match the unix
semantics.
</P>
<BR>[DONE] Irfan fixed the <CODE>ACE_OS::recvfrom()</CODE>
function.
</LI>
<LI><P><B>EC:</B> When shuting down a reactive Event Channel the
timeouts for the EC have to be cancelled.
It would seem like the proper way to do that is to do it in
the <CODE>shutdown()</CODE> method of the
<CODE>Timer_Module</CODE>.
<BR>[DONE]
</P>
</LI>
<LI><B>EC:</B> Improve configuration support in the EC, give an
example of a single threaded EC, support different dispatching
strategies, etc.
<BR>[DONE] But there are a few bugs to remove.
<P></LI>
<LI><B>EC:</B> Correlation in the EC has a bug [?]
<BR>[DONE] Added a correlation test into the EC_Basic test,
this does not mean that all bugs have been removed, but we
don't know of any remaining bugs.
<P></LI>
<LI><P>The methods in <CODE>CORBA::TypeCode</CODE> should be
<CODE>const</CODE>.
</P>
<BR>[DONE]
</LI>
<LI><P>Add the <CODE>CORBA::TypeCode::_tc_Bounds</CODE> and the
<CODE>CORBA::TypeCode::_tc_BadKind</CODE> type codes.
Currently they are in the wrong namespace (just
<CODE>CORBA::_tc_Bounds</CODE>).
</P>
<BR>[DONE]
</LI>
<LI><P>Add compiled marshalling
<BR>[STATUS] Andy is working on this.
<BR>[DONE] The compiled marshaling code works, we still have
to fine tune it a bit.
</P>
</LI>
<LI><P>Implement the new DynAny types.
<BR>[STATUS] Jeff is working on this.
<BR>[DONE] More testing is needed, but the basics are
there.
</P>
</LI>
<LI><P><B>EC:</B>The <CODE>TAO_EC_Gateway_IIOP</CODE> class
receives events from a "remote" EC and pushes them on the
local EC.
The subscription and publication list for the Gateway are
the disjunction of the local EC consumer subscriptions.
Unfortunately this can result in multiple supplier_IDs for
the Gateway, the current implementation is not prepared to
handle this.
The Gateway must keep a list of suppliers, each one with a
different supplier id,
when it receives a remote event it should push the event
only to the right supplier.
It must also keep another supplier used for the events that
are of interest by their event type, regardless of their
supplier ID.
<BR>[DONE]
</P>
</LI>
<LI><P><B>EC:</B>The Event Channel must be able to accept more
than one supplier with a given supplier ID, or at least we
should be able to configure the EC to work in such a mode.
This is required for some applications that treat the
supplier ID as a "supplier type".
<BR>[DONE]
</P>
</LI>
<LI><P><B>EC:</B>If a Supplier disconnects while it has
consumers registered for it's Supplier_ID,
the consumers are not connected again even if the supplier
reconnects.
<BR>[DONE]
</P>
</LI>
<LI><P>Further optimize memory allocation by using a memory pool
for the incoming CDR stream.
<BR>[DONE] The pool is configurable for the users that may
want to steal the CDR buffer.
</P>
</LI>
<LI><P>The nested upcall support must be strategized,
some applications don't need this feature,
other applications are single threaded or use an
ORB-per-thread concurrency policy,
so using a full-blown leader follower in all cases can
result in a significant slow down.
It seems like the right way to
strategize this by changing the Client_Connection_Handlers.
<BR>[DONE] Irfan and Carlos are finished this task.
</P>
</LI>
<LI><P>Use active demuxing in the POA to locate servants in
constant time, as well as active demuxing
in the skeletons to locate operations in constant time.
<BR>[DONE] Irfan finished this task.
</P>
</LI>
<LI><P>Sometimes the ORB picks up the wrong name on multi-homed
hosts,
the <CODE>ACE_INET_Addr</CODE> class uses
<CODE>gethostbyaddr_r</CODE> to convert from the address into
a hostname, but it only uses the first alias.
<BR>[DONE] The current implementation tries to use the
alias that more closely matches the address of the given
host.
</P>
</LI>
<LI><P>Many of the test programs in the
<CODE>$TAO_ROOT/tests</CODE> hierarchy are actually sample
programs or performance tests.
</P>
<P>We need to re-organize this hierarchy, following the ACE
scheme:
<UL>
<LI><B>tests</B> for programs that do regression testing.
</LI>
<LI><B>examples</B> for programs that illustrate how to use
TAO, a service or a component
</LI>
<LI><B>performace-tests</B> for programs that are used in
performance measurements
</LI>
</UL>
the same hierarchy may be needed in
<CODE>$TAO_ROOT/orbsvcs</CODE>.
<BR>[DONE] Doug did this changes already, minor revisions
many be necessary, and orbsvcs is still pending.
</P>
</LI>
<LI>Cleanup memory managment in some of the servers, for
instance: Naming still believes that controlling the memory
for a stub will control the servants, this is not true
anymore.
<BR>[DONE] Marina fixed the Naming Service, the other services
are working OK also.
<P></LI>
<LI><P>The mapping for the CORBA <CODE>boolean</CODE> type does
not require the <CODE>CORBA::TRUE</CODE> constant,
but it never mentions the <CODE>CORBA::B_TRUE</CODE> constant
either; in fact it recommends the usage of the literals
<CODE>0</CODE> and <CODE>1</CODE>.
We should move to use the <CODE>CORBA::TRUE</CODE> style,
because other ORBs offer the same feature,
but only use the literals,
to show the "Right Way"[tm] of doing CORBA things.
</P>
<BR>[DONE] Irfan removed the <CODE>CORBA::B_TRUE</CODE> and
<CODE>CORBA::B_FALSE</CODE> constants and replaced them with
the compliant <CODE>0</CODE> and <CODE>1</CODE>
</LI>
<LI><P>Add an option to the IDL-compiler (e.g. -rp) meaning
"generate relative include paths".
<BR>[STATUS] Alex is working on this.
<BR>[DONE]
</P>
</LI>
<LI><P>Add the <<= and >>= operators for
<CODE>CORBA::TypeCode</CODE>
<BR>[DONE] Jeff added the operators</P>
</LI>
<LI>The IDL compiler should generate the code locally (not in
the directory where the .idl resides) or at least give an
option to do so
<BR>[DONE] Alex completed this, he even added an option to
select the output directory.
<P></LI>
<LI>Are nested upcalls in different concurrency models, like
thread-per-connection working?
<BR>[STATUS] Irfan reports that this works correctly with
<CODE>thread-per-connection</CODE>
<BR>[DONE] The <CODE>NestedUpcall/Reactor</CODE> test is
giving the same results with either
<CODE>thread-per-connection</CODE> or <CODE>reactive</CODE>
strategies.
<P></LI>
<LI>Normalize the compiled marshalling interface: the IDL
compiler is going to generate a different interface than the
code I showed in the EC_Custom_Marshal example; we need to
make all the code consistent so users have easy access to it.
<BR>[DONE]
<P></LI>
<LI>Object references inside structures or sequences are not
decoded properly, the problem starts because the interpreter
expects a CORBA::Object_ptr, but the real type is a T_var;
virtual inheritance adds the last ingredient to the poison.
<BR>[STATUS] A possible solution is to use a T_manager_var that
has two fields a Object_ptr and a T_ptr....
<BR>[DONE] The solution was to use
<CODE>TAO_Object_Field_T<T></CODE>, that
behaves like the _var classes, but extends them to provide
virtual methods to <CODE>_upcast()</CODE> and
<CODE>_downcast()</CODE> to and from
<CODE>CORBA_Object_ptr</CODE>.
Similar methods were added to sequences of objects.
<P></LI>
<LI>Add options to the IDL compiler to set the suffixes.
<BR>[DONE] Alex finished this.
<P></LI>
<LI>Support for 64bit longs in the IDL compiler
<BR>[DONE] They were supported already, but we had to test
them, I added a test to Param_Test.
<P></LI>
<LI>The do_static_call() and do_dynamic_call() methods should
use an array of <CODE>void*</CODE>
(in the first case static and generated by the IDL compiler);
this will remove the problems with g++ and probably work
faster.
<BR>[DONE]
<P></LI>
<LI>The IDL compiler gets confused with paths in NT, this may be
due to my changes to report errors correctly (coryan).
<BR>[STATUS] Creating a Win32 workspace to try it.
<BR>[DONE]
<P></LI>
<LI>The current implementation of octet sequences based on
message blocks has a few problems, it cannot marshall
chains of message blocks properly.
Notice that complete support for chains of message blocks will
complicate the sequence of octets implementation (like
operator[]) and will make others either hard or expensive
(like get_buffer ()).
<BR>[STATUS] It seems like the best tradeoff would be to
support the chain during marshalling, but disable or give no
warranties for operator[] and get_buffer().
<BR>[DONE]
<P></LI>
<LI>Debug Memory Pools in the EC there seem to be a problem when
sending multiple events in a row (a memory leak, limit or
corruption).
<BR>[DONE]
<P></LI>
<LI>Add suspend and resume operations to the PushConsumerProxy
and PushSupplierProxy interfaces, following the Notification
Service spec.
<BR>[DONE]
<P></LI>
<LI>Optimize connection lookup in the client side, using "hints"
from the previous lookup, or keeping smaller sets on each IIOP
profile or a combination of both.
<BR>[STATUS] Irfan is working on
this.
<BR>[DONE]
<P></LI>
<LI>Optimize the outgoing CDR streams by using TSS memory pools
for both the data blocks and the buffers.
<BR>[DONE] But we may consider strategizing the kind of allocator
we use (like using a free list instead of a generic
ACE_Malloc).
<P></LI>
<LI>Optimize Octet Sequences.
<BR>[DONE]
<P></LI>
<LI>Obtain results for the EC_Multiple test.
<UL>
<LI>Latency seems OK.
<P></LI>
<LI> Overhead: need lower priority for scavenger thread.
<P></LI>
</UL>
<P></LI>
<LI>Debug EC_Multiple.
<P></LI>
<LI>Your next assignment: Regenerate all methods in
_tao_collocated to avoid "inherit via dominance" warnings.
<BR>[STATUS] The IDL compiler was modified to generate a
suitable
<CODE>#pragma</CODE> that removes the warning, it reenables
the warning when leaving the file
<P></LI>
<LI>Remove the SOLARIS2 macro from the TAO_IDL compilation.
<BR>[DONE]
<P></LI>
<LI>Remove the preemption_prio message from Scheduling_Service.
<P></LI>
<LI>The ORB core should be able to choose the right port for us
(in other words -ORBport 0) should work.
<BR>[DONE]
<P></LI>
<LI>Client side optimization for Octet Sequences.
<BR>[DONE]
<P></LI>
<LI>Minimize memory allocation in TAO
<BR>[STATUS] Down to 3 on the client side and 4 on the server
side.
<BR>[STATUS] For oneways it is down to 0 (for the common case)
on the client side and 2 on the server side. For twoways it is
2 on both sides.
<P></LI>
<LI>Automate subscription and publication list generation in the
EC_Gateway.
[VERY important for Boeing]
<BR>[STATUS] Completed and debugged, but the EC is still
buggy.
<P></LI>
<LI>Debug EC shutdown and startup....
[Specially startup for Boeign, but shutdown is important for
Purify and Quantify]
<BR>[STATUS] Shutdown is clean and startup of threads can be
controlled by the user.
<P></LI>
<LI>Support a chain of Message Blocks in Output CDRs and use
writev() to write them.
<BR>[DONE]
<P></LI>
<LI>Memory managment in the demarshalling engine, it is not
clear that the current scheme works in all cases (like
sequences of unions of anys).
We also need to fix sequences of object references: how does
the demarshalling engine learn about the dynamic type of the
objects?
Closely related to this is the problem of memory alignment for
different architectures, we need to develop strategies for each
one (they should only be a few) and choose the right one.
<BR>[STATUS] This seems to be working for most of the cases, the
main idea is to delay demarshalling until enough information
is available, for instance, when decoding an Any just a
reference to the CDR stream is stored, decoding actually
happens when the user invokes >>= on the any (at that point
all the info is there).
<P></LI>
<LI>Add a new Profile type that includes the QoS info and using
for end-to-end QoS preservation.
[DEPRECATED] The IIOP 1.1 Profiles can handle that.
<P></LI>
<LI>Show an example of the
<CODE>sequence<octet></CODE> and CDR streams.
<BR>[DONE] But the example could also include the marshalling of
plain C++ types.
<BR>[DONE too]
<P></LI>
<LI>Test anys in the EC.
<BR>[DONE] Michael reported that they work OK on NT.
<P></LI>
<LI>UDP for event channel and Multicast support in the EC.
<BR>[STATUS] Manual configuration using Suppliers and Consumers is
possible, automation is under research.
<P></LI>
<LI>Unbind the EC and scheduling service from the Naming
Service.
<BR>[DONE] For the Event_Service and the examples.
<P></LI>
<LI>Optimize oneways by not allocating the memory for the return
buffers.
<BR>[DONE] Added different Invocation classes for each case.
<P></LI>
<LI>Fix the _non_existent call.
<BR>[DONE] The client side semantics match the new clarifications
of the C++ RTF, the server side is implemented by the IDL
compiler, though t could be a good idea to put that in the
POA.
<P></LI>
<LI>Simplify EC configuration, a Factory class must provide the
Dispatching, Supplier, Correlation and any other Modules that
are required.
This is the right spot to add trivial Dispatching or
Correlation Modules and to dynamically load and configure the
EC.
<BR>[DONE] A Factory class is used to create the modules, only the
default factory is implemented so far.
<P></LI>
<LI>Fix the ACE_Thread_Condition madness.
<BR>[DONE] We changed ACE so ACE_SYNCH_CONDITION expands to
ACE_Condition_Thread_Mutex
<P></LI>
<LI>Reference counting should have locks, but we should remove
all the QueryInterface madness to make that work. The policy
for references in multiple threads is: the reference count
must be >2 if that happens.
<BR>[STATUS] The QueryInterface method (all the COM stuff for that
matter) was removed...
<BR>[DONE]
<P></LI>
<LI>Reference counting for Typecodes is completely broken.
<BR>[DONE]
<P></LI>
<LI>Under g++(2.7.2) the use of multiple inheritance in IDL
triggers some compiler bug, if the IDL explictly generated the
copy constructor for the skeletons (the POA_ classes) the
problem would go away.
<BR>[DONE] Fixed, Seth is testing the fixes and will commit them
soon (Tue Jul 21 14:24:56 CDT 1998)
<P></LI>
<LI>The octet sequence optimization causes problems when Anys
get into the game.
<BR>[DONE] Seth reported that the problem was not real.
<P></LI>
<LI>The DEEP_FREE method is also broken, sometimes we need to
release the top-level memory, sometimes not.
<BR>[DONE] We always release the memory in the Any, it was failing
due to weird interactions between the Environment containing
an exception and the Any that also did.
<P></LI>
<LI>Improve error messages in the IDL compiler.
<BR>[DONE] At least the filename is correct now.
<P></LI>
<LI>Support for arrays in the IDL compiler is incomplete,
specially anonymous arrays.
<BR>[DONE] According to Andy this is properly supported by the IDL
compiler now.
<P></LI>
<LI>Prepare the 0.2 release:<P>
<OL>
<LI>Execute all the tests in $TAO_ROOT/tests
</LI>
<LI>Run Param_Test (SII) and record what fails and what works.
</LI>
<LI>Run Param_test (DII) and record what fails and what works.
</LI>
<LI>Run Param_Test across Endian Borders.
</LI>
</OL>
<BR>[DONE] At last!
<P></LI>
<LI>Move this list to the release notes.
<P></LI>
</OL>
<HR>
<P>Back to the TAO <A HREF="../index.html">documentation index</A>. <!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</HTML>
|
