Re: [certi-dev] HLA 1516 - Circular dependency between RTI1516 and FedTime1516?

[Eric Noulard]

2010/4/6 Ijperen, Jeroen van <address@hidden>:
> Hello guys,
>
> I was wondering if any of you could have me analyze the following problem: 
> from what I've noticed there seems to be a circular dependency in the HLA 
> 1516 specification, between the LogicalTime module, and the actual RTI1516 
> module.

Yes there is and this is definitely a design flaw (My personal point of view).

We did face the same issue when we decided to build a separate libFedTime
see:
https://savannah.nongnu.org/bugs/index.php?24930

Currently the "not so good solution" is to avoid the dependency by not
throwing any exception
in our libFedTime. Thus the warning:

/DATA/ERIC/workspace/certi/libRTI/RTIfedTime.cc: In function ‘const
RTIfedTime&<unnamed>::rft(const RTI::FedTime&)’:
/DATA/ERIC/workspace/certi/libRTI/RTIfedTime.cc:51: attention :
contrôle a atteint la fin non void de la fonction
/DATA/ERIC/workspace/certi/libRTI/RTIfedTime.cc: In static member
function ‘static RTI::FedTime* RTI::FedTimeFactory::decode(const
char*)’:
Linking CXX shared library libFedTimed.so
/DATA/ERIC/workspace/certi/libRTI/RTIfedTime.cc:92: attention :
contrôle a atteint la fin non void de la fonction
/DATA/ERIC/workspace/certi/libRTI/RTIfedTime.cc: In static member
function ‘static RTI::FedTime* RTI::FedTimeFactory::makeZero()’:
/DATA/ERIC/workspace/certi/libRTI/RTIfedTime.cc:75: attention :
contrôle a atteint la fin non void de la fonction

> The LogicalTime module specifies that a federate should contain an 
> implementation for the LogicalTime interface, which specifies that it should 
> have certain functions, and can throw certain exceptions. This means it needs 
> to import things like 'VariableLengthData' and exceptions from the RTI1516 
> Module.
>
> The RTI1516 module in turn requires LogicalTime objects for certain 
> functions, making it depend directly on the/an LogicalTime module.

Exactly.


> As far as I can see, this cannot be solved except by changing the standardized
> header files, which would defeat their purpose.

There should be at least 2 "theoretical" solutions:

 1) Break the circular dependency by not throwing any exception in
libFedTime (thus you do not import RTI15616 etc...)

 2) Compile twice, the first compilation will fail, the second one will work.
     [this second solution may not be implemented using CMake because
Cmake refuse the circular dep' alltogether]

> Am I missing something?

Nope I think your analysis is ok, I'm sorry I may have warn you about
this, however
I'm glad we end up to the same conclusion.

As a complement, note that this problem only occurs on Windows
platform because on Windows
the DLL have to "export/import" the symbols
on most unix platform the default is to export all symbols which leads
to easiest circular dependency.

That said this design is simply broken.
The fact that it is implementable on Unix is not an argument.
LibFedTime should NEVER have to refer to libRTI --fullstop.

I eagerly waiting for IEEE-1516 v2010 (aka HLA Evolved) in order to
see if this has been fixed/changed.

May be 3) solution would be to duplicate the imported code both in
libFedTime and libRTI
and let the dynamic loader chose the appropriate duplicate, I don't
even know if it works.

Commercial RTI I know do exhibit this circular dep (observed with DLL
explorer or similar tool)
but I don't know how they compile that. And I didnt' asked :-)

Now I'm not a Windows expert so may be there exist some better tricks
to deal with this kind of issue.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org