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
|
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (X11; I; Linux 2.0.30_SMP i686) [Netscape]">
<TITLE>TAO Release Information and TODO List</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<!-- $Id$ -->
<CENTER>
<HR>
<H3>
Release Information for The ACE ORB (TAO)</H3></CENTER>
Information is available on the following topics related to the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/VERSION">current release</A> of
<A HREF="TAO.html">TAO</A>:
<UL>
<LI>
<A HREF="orbcore.html">ORB & ORB Core</A></LI>
<LI>
<A HREF="#idl">IDL Compiler</A></LI>
<LI>
<A HREF="#eventchannel">Event Channel</A></LI>
<LI>
<A HREF="#apps">Test & Example Applications</A></LI>
<LI>
<A HREF="#poa">Portable Object Adapter</A></LI>
<LI>
<A HREF="#nservices">CORBA Naming Service</A></LI>
<LI>
<A HREF="#tservices">CORBA Trader Service</A></LI>
<LI>
<A HREF="#ace">ORB-related ACE Changes</A></LI>
</UL>
<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/orbcore.html" -->
<HR>
<H3><A NAME="idl"></A>IDL Compiler</H3>
Point of contact: <A HREF="mailto:gokhale@cs.wustl.edu">Aniruddha Gokhale</A>
<P> Current status: (As of Nov 25th, 1997.)
<UL>
<LI> Generated code closely follows the C++ Mapping specified in
the POA Specification (ORBOS/97-05-15). </LI>
<LI> Many IDL constructs supported including primitive types,
typedefs, sequences, structures, and unions. </LI>
<LI> Generates C++ stubs and skeletons that use TAO's <A
HREF="http://www.cs.wustl.edu/~schmidt/HICSS-97.ps.gz">interpretive IIOP protocol
engine</A>. </LI>
<LI> Include files are handled properly. So are the definitions
used inside the include files that are used in the currently
parsed files. </LI>
<LI> The problems arising due to public virtual inheritance when
casting from an interface class to CORBA::Object_ptr has
been solved. We do this casting inside the stubs/skeletons
rather than first converting an interface class pointer to a
void*, storing it in an Any, and casting it to
CORBA::Object_ptr in the encode/decode methods. The casting
inside the stubs/skeletons work because the compiler has
knowledge of both types. </LI>
<LI> IN, INOUT, and OUT object reference parameters are now
supported properly. We think the same approach should work
for sequences, structs, and unions. </LI>
<LI> Support for attributes completed and is currently undergoing
testing </LI>
<LI> The latest success story is that the compiler
generates correct code for COSS Naming service and it
runs properly. Correct code also gets generated for the
Event Channel program </LI>
</UL>
<P> Known bugs:
<UL>
<LI>Works for <I>most</I> IDL constructs. Some of the known
bugs/incomplete tasks are:
<UL>
<LI> Problems when interfaces use single or multiple
inheritance. The problem is with the demultiplexing
code. </LI>
<LI>
Sequences of strings and object references still
pose problems </LI>
<LI>
TypeCode generation for multidimensional arrays and
indirected typecodes is still a problem. </LI>
<LI>
Exceptions are not well-supported. TAO does not use
C++ Exceptions. Instead we use the alternative
mapping that uses CORBA::Environment. </LI>
<LI> Unions with default cases yet to be handled </LI>
<LI> The <<= and >>= operators for user-defined types
are not generated yet. </LI>
<LI> Deal with names in the IDL definition that are C++
keywords. </LI>
</UL>
</LI>
</UL>
Future work:
<UL>
<LI>Improve IDL compiler to support complete IDL-to-C++ mapping.</LI>
<LI>Fix bugs in the SunSoft IDL front-end we've
uncovered. These primarily include support for Unions.</LI>
<LI>Add command line options to TAO IDL. These options will
decide what strategy to use for operation name
demultiplexing. Another option may decide whether to use
the interpretive IIOP engine or generate compiled
stubs/skeletons. </LI>
<LI>Use <A
HREF="http://www.cs.utah.edu/projects/flux/flick/">Flick</A>
(from the University of Utah) to generate compiled stubs.</LI>
<LI>Goal is to measure the code size of the interpretive stubs
generated by TAO IDL compiler <I>vs</I> code size of compiled
stubs. Then compare the performance of each. We want to prove
the thesis that TAO IDL compiler generated interpretive stubs
have a small code size, yet are comparable in performance (or
slightly less) than compiled stubs. Hence, it will be useful
for small distributed equipment such as handsets, PDAs,
etc.</LI>
<LI>In doing the above, improvements to the IIOP protocol
engine in terms of size/performance/determinism will be
made.</LI>
</UL>
<HR>
<H3>
<A NAME="eventchannel"></A>Real-time Event Channel</H3>
Point of contact: <A HREF="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</A>
<P>Current status:
<UL>
<LI>
The current Event Channel is running under Orbix, fully distributed, the
main test has three processes, one runs the EC itself, one a Supplier and
yet another a Consumer.</LI>
<LI>
The configuration runs can be done even on the distributed scenario, using
the Real-time "Scheduling Service", which now has an IDL interface.</LI>
<LI>
At run-time (no config runs) there is no need to use the Real-time Scheduling
Service, a faster, collocated implementation for the service is available.
Obviously the information is generated on the config runs and linked into
the program.</LI>
<LI>
We are using an implementation of the standard <A HREF="#naming">Naming
Service</A> for Orbix.</LI>
</UL>
Future work:
<UL>
<LI>
Port to TAO (once IDL compiler is available and stable).</LI>
<LI>
The Scheduling Service is completely independant of the EC and the configuration
of suppliers or consumers. I think it would be convenient to have a library
and binaries for it, including a tool to dump the results in a C++ compilable
form.</LI>
</UL>
<HR>
<H3>
<A NAME="apps"></A>Test & Example Applications</H3>
Point of contact: <A HREF="mailto:sumedh@cs.wustl.edu">Sumedh Mungee</A>
<P>Current status:
<P>The TAO test application is meant to serve as a starting point for real-time
tests on the TAO system. It comprises the following parts:
<UL>
<LI>
<I>Server.</I> The server creates multiple CORBA objects (servants),
each with different real-time priorities. This priority is implemented
by using real-time thread support provided by the operating
system. Thus, requests sent to a high-priority servant are handled by
a high-priority real-time thread, and those sent to a lower priority
servant are handled by correspondingly lower priority threads. <P>
<LI>
<I>Client.</I> The client component binds to the servants, and sends a
stream of CORBA requests to the servants. It measures the response time,
i.e. the time taken for the request to complete successfully. In particular,
it measures the time taken for requests sent to the high priority servant
to complete. The volume of lower priority requests is configurable. The
client is thus able to measure the performance of the high-priority servant
in the presence of competition from several lower-priority servants.</LI>
</UL>
Clearly, if the ORB endsystem handles the priorities of the various requests
correctly, increasing the volume of lower priority requests should not
affect the performance seen by the higher priority requests. The application
thus serves as a tool to measure and confirm this behavior.
<P>Future work:
<UL>
<LI>
Study the impacts of scheduling & concurrency strategies on performance.</LI>
<LI>
Evolve into a testbed for discovering sources of performance non-determinism
& priority inversion.</LI>
</UL>
<HR>
<H3>
<A NAME="poa"></A>Portable Object Adapter</H3>
Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>
<P>Current Status:
<UL>
<LI>
The POA is not integrated into this release, though we've begun migrating
TAO's OA to use POA method names.</LI>
</UL>
Critical work:
<UL>
<LI>
Re-generate win32 project files with new file names.</LI>
<LI>
Add resolve_initial_references() to resolve the "RootPOA" entry.</LI>
</UL>
Future work:
<UL>
<LI>
Mostly compliant with the <A HREF="http://siesta.cs.wustl.edu/~cleeland/tao/POA.pdf">ORB
Portability Specifications [orbos/97-05-15]</A> published by OMG.</LI>
<LI>
Provide extensions of the specification to ensure real-time delivery of
messages.</LI>
</UL>
<HR>
<H3>
<A NAME="nservices"></A>CORBA Naming Service</H3>
Point of contact: <A HREF="mailto:sergio@cs.wustl.edu">Sergio
Flores-Gaitan</A> and <A HREF="mailto:marina@cs.wustl.edu">Marina
Spivak</A><P>
<P>Current status:
<UL>
<LI>
This implementation works with TAO.</LI>
</UL>
<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/trader.html" -->
<HR>
<H3>
<A NAME="ace"></A>ORB-related ACE Changes</H3>
Points of contact: <A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</A> and <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyrarli</A>
<P>Recently Completed Work:
<UL>
<li>Added special declaration to OS.h for <code>inet_ntoa</code>
and other functions because VxWorks doesn't provide full
argument prototypes for these library functions.</li>
<li>The current caching connector behaves properly in the face
of a non-blocking connect request. The "fix" is simply to not
support non-blocking connects through the cache. When the
<code>connect()</code> fails with <code>EWOULDBLOCK</code>,
morph the error to -1 and clean up the request.</li>
<li> Service handlers obtained from the caching connector are
now cleaned up. The application needs to be able to signal that
it's not using it any longer, and, when the application encounters
an error, needs to effectively close down that connection for good
so that a new connection can be initiated. <br>
Added the ability for a Svc_Handler to
recycle itself. idle() can be called when the Svc_Handler is
done serving a particular connection and can how be recycled.
The Svc_Handler now also has a pointer to a recycler that is
responsible for managing the connections. The recycler is
usually a Cached_Connector. <br>
Added new class ACE_Recycling_Strategy.
It defines the interface (and default implementation) for
specifying a recycling strategy for a Svc_Handler. This
strategy acts as a consular to the Svc_Handler, preparing it for
the tough times ahead when the Svc_Handler will be recycled. <br>
Added new class ACE_NOOP_Concurrency_Strategy. It implements
a no-op activation strategy in order to avoid calling open on
a recycled svc_handler multiple times. <br>
ACE_Cached_Connect_Strategy now
implements the ACE_Connection_Recycling_Strategy interface.
This allows Svc_Handlers to cache themselves with
ACE_Cached_Connect_Strategy when they become idle. It also
allows them to purge themselves from the connection cache when
the Svc_Handlers close down. <br>
Also added ~ACE_Cached_Connect_Strategy that will cleanup up the
connection cache. </li>
</UL>
<P>Future work:
<blockquote>
<em>None currently scheduled.</em>
</blockquote>
</BODY>
<hr><P>
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</HTML>
|
