bugCERTI - Bugs: bug #27343, tick() does process only 1 callback

 
 

bug #27343: tick() does process only 1 callback

Submitter:  Petr Gotthard <gotthardp>
Submitted:  Fri 28 Aug 2009 01:02:41 PM UTC
   
 
Category:  CERTI Severity:  * 3 - Normal
Item Group:  HLA compliance error Status:  Fixed
Privacy:  Public Assigned to:  gotthardp
Open/Closed:  Closed Release:  * CVS
Reproducibility:  Intermittent Fixed Release:  * 3.3.3
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 27 Sep 2013 08:06:47 AM UTC, comment #15: 

This bug has been solved a long time ago.
tick() can now process several callback.
This should be available since CERTI 3.3.3.

Eric NOULARD <erk>
Group administrator
Tue 01 Sep 2009 07:27:35 AM UTC, comment #14: 

What do you mean by "It does not work for the examples"?
I did pass HLA TestSuite and HLA Tutorial without trouble.

Ok now I think I get it.
You mean if you have some Federate application,
how would he choose libRTI vs libRTI-NG vs ...?

I think the example Federate should be specific to
the RTI version he wants to use:
  RTI-Legacy
  HLA13-NG
  IEEE-1516

By specific I mean that there must be either
totally separate source files or may be COMPILE_FLAGS configurable source file (just as the libRTI source files),
in the end you'll definitely have 2 executables linked
to the unique appropriate lib.

In the same way FindRTI.cmake
may try to build the appropriate set of variables:

RTI_HLA13_LIBRARY
RTI_IEEE1516_LIBRARY
...
the federate then chose the appropriate var.

or alternatively indicates FindRTI.cmake which
version you want.
SET(RTI_WANTS HLA13)
find_package(RTI REQUIRED)

Note that may be the "version" argument of
find_package is usable for that purpose but
I did not try to use to the new XXX-Config.cmake
and XXX-Version.cmake stuff.

The baseline is:

 - RTIA/RTIG will possibly be unique and
   linked to the unique libCERTI.
   If ever we hit the wall of uniqueness for libCERTI/RTIA/RTIG
   then we will have to have a whole set of separate libs and exe.
   However we can still compile all variants from the same source
   tree and have the different variant INSTALLed in different
   places. Or we can force the separate build of each variant
   in separate build tree.

 - libRTI/libFedTime etc.. are specific and
   so are the Federate.

I'd like to begin with unique RTIA/RTIG/libCERTI solution
we will soon see if it's manageable or not.

What do you think?

Eric NOULARD <erk>
Group administrator
Mon 31 Aug 2009 04:01:24 PM UTC, comment #13: 

Aaaaagr! Works for RTIA/RTIG, but not for the examples.

Questions like these need to be answered: Two sets of examples, or libRTI dependent examples? What libRTI to use if two are being compiled?

Petr Gotthard <gotthardp>
Group Member
Mon 31 Aug 2009 02:56:23 PM UTC, comment #12: 

Done.
I did fix the spurious dependency,
commited to CVS and added a link between the 2 bug rep.
I think we may generate both libs but I did not tried.

Will do that later unless you want to try.
Note that generating both libs may puzzle the
FindRTI.cmake work.

Eric NOULARD <erk>
Group administrator
Mon 31 Aug 2009 02:17:44 PM UTC, comment #11: 

The answer would be "they depend on each other because it's written in so the CMakeLists.txt" ;-) I didn't thought it thoroughly. :-/

Petr Gotthard <gotthardp>
Group Member
Mon 31 Aug 2009 02:10:02 PM UTC, comment #10: 

Thank Petr,

but...I was puzzled by the question
Why on earth would rtia and rtig executable be dependent
on libRTI or libFedTime???

The answer would be "because they use RTI:: something"...
In fact we don't do this anymore since YOU separate
the libCERTI world from the libRTI world in order to
avoid the circular ref. headache on windows.

So I took away the spurious
TARGET_LINK_LIBRARIES(rtia CERTI RTI FedTime)
TARGET_LINK_LIBRARIES(rtig CERTI RTI FedTime)
for
TARGET_LINK_LIBRARIES(rtia CERTI)
TARGET_LINK_LIBRARIES(rtig CERTI)
and guess what ... it works "as expected".

I'll open a bug + commit the corresponding change in a minute
or so.

Eric NOULARD <erk>
Group administrator
Mon 31 Aug 2009 01:31:10 PM UTC, comment #9: 

Implemented the tick() and #ifdef check as discussed.

Implemented an exclusive BUILD_LEGACY_LIBRTI option. Cannot build two libRTI libraries, because it would have to build also two rtia a rtig executables.
I think it's more convenient to let user to do manually the build twice, if two libraries are really needed.

Petr Gotthard <gotthardp>
Group Member
Mon 31 Aug 2009 12:49:13 PM UTC, comment #8: 

One more comment.
Imagine we have 3 versions of libRTI

HLA13NG
IEEE1516
LEGACY

we would have 3 CMake options:
OPTION(BUILD_HLA13NG_LIBRTI "Build CERTI HLA 1.3 NG libRTI" ON)
OPTION(BUILD_IEEE1516_LIBRTI "Build CERTI IEEE-1516 libRTI" OFF)
OPTION(BUILD_LEGACY_LIBRTI "Build CERTI legacy libRTI" ON)

which defines corresponding compile flags:
HLA13NG_LIBRTI, IEEE1516_LIBRTI, LEGACY_LIBRTI

we should carefully write cpp macro in the source in
order to be sure there will be a compile error if
ever 2 flags are defined together:


#ifdef HLA13NG_LIBRTI
   __tick_kernel(RTI_TRUE, 0.0, 0.0);
#endif
#ifdef LEGACY_LIBRTI
   __tick_kernel(RTI_FALSE, 0.0, 0.0);
#endif

may not be enough, we should write:

#if defined(HLA13NG_LIBRTI) && !defined(LEGACY_LIBRTI)
   __tick_kernel(RTI_TRUE, 0.0, 0.0);
#endif

or may be
#ifdef HLA13NG_LIBRTI
   __tick_kernel(RTI_TRUE, 0.0, 0.0);
#else
   #ifdef LEGACY_LIBRTI
   __tick_kernel(RTI_FALSE, 0.0, 0.0);
   #else
     #error "At least one LIBRTI flag should be defined"....
   #endif
#endif

i.e. protect ourself from double definition or "none" definition
even if "none" could have a default...

Eric NOULARD <erk>
Group administrator
Mon 31 Aug 2009 12:39:21 PM UTC, comment #7: 

Yes you are totally right
BUILD_LEGACY_LIBRTI is a better name if we build
both libs.

Then
OPTION(BUILD_LEGACY_LIBRTI "Build CERTI legacy libRTI" OFF)

then later in libRTI/CMakeLists.txt:

we should have different ADD_LIBRARY:

ADD_LIBRARY(RTI ${RTI_LIB_SRCS} ${RTI_LIB_INCLUDE})
TARGET_LINK_LIBRARIES(RTI CERTI FedTime)
SET_TARGET_PROPERTIES(RTI PROPERTIES OUTPUT_NAME "RTI-NG")
SET_TARGET_PROPERTIES(RTI PROPERTIES VERSION 1.0.0 SOVERSION 1)

IF (BUILD_LEGACY_LIBRTI)
  ADD_LIBRARY(RTI-Legacy ${RTI_LIB_SRCS} ${RTI_LIB_INCLUDE})

  # Add target specific compiler option
  SET_TARGET_PROPERTIES(RTI-Legacy PROPERTIES
                        COMPILE_FLAGS -DLEGACY_LIBRTI)

  TARGET_LINK_LIBRARIES(RTI-Legacy CERTI FedTime)
  SET_TARGET_PROPERTIES(RTI-Legacy PROPERTIES OUTPUT_NAME "RTI")
  SET_TARGET_PROPERTIES(RTI-Legacy PROPERTIES VERSION 1.0.0 SOVERSION 1)
ENDIF(BUILD_LEGACY_LIBRTI)

This is the somehow simplest case where we compile
the exact same set of files for building 2 differents
libraries. The difference are handled with compile flags options.
This will cost us more compile time but not much more.

This is handled in the source code by
#ifdef LEGACY_LIBRTI

#endif

Using this scheme we may build several version of
 "the same libs".
Note that we can have files which are compiled in for some
lib and for the other.

Concerning the 1516 libs variant we could do the same:

OPTION(BUILD_IEEE1516_API "Build CERTI IEEE-1516 API" ON)

which would build yet another libRTI1516.*

we should try hard to keep libCERTI unique but in fact
we may end up forced to have libCERTI and libCERTI-1516
variant etc...

Each new "optional" target should have its own set of rules:
ADD_LIBRARY/ADD_EXECUTABLE
SET_TARGET_PROPERTIES
TARGET_LINK_LIBRARIES
INSTALL
etc...

Eric NOULARD <erk>
Group administrator
Mon 31 Aug 2009 12:13:29 PM UTC, comment #6: 

I thought the switch should also change the library name to libRTI. Otherwise we get two libraries of the same name with different behaviour.
This means the option should be like BUILD_LEGACY_LIBRTI.

But-- In future we may also need a switch to enable the IEEE library. So I wonder if there is a way in cmake to have one option to configure all libRTI variants.

Petr Gotthard <gotthardp>
Group Member
Mon 31 Aug 2009 11:50:36 AM UTC, comment #5: 

Usually the best way to go is to use
an OPTION with an appropraite default value.
This is what we currently use for RPATH handling
(look at the main CETI/CMakeLists.txt)

would be something like:

#
# Some comment to explain the option
#
OPTION(BUILD_LEGACY_CERTI_TICK
 "The tick() function should have the legacy CERTI behavior " OFF)

I usually only put OPTION only in the main CMakeLists.txt
but that one may well be put in the libRTI/CMakeLists.txt.

then in the libRTI/CMakeLists.txt
IF(BUILD_LEGACY_CERTI_TICK)
   ADD_DEFINIION(-DLEGACY_CERTI_TICK)
ENDIF(BUILD_LEGACY_CERTI_TICK)

Eric NOULARD <erk>
Group administrator
Mon 31 Aug 2009 10:29:15 AM UTC, comment #4: 

Eric, I have a question for you as a cmake expert ;-)

What would you think is the best approach to let the user configure the different interface variants?

Petr Gotthard <gotthardp>
Group Member
Sat 29 Aug 2009 01:42:07 PM UTC, comment #3: 

Agreed for libRTI vs libRTI-NG policy.

CERTI-compile time switch suppose users will build CERTI
themselves and use it either way (RTI or RTI-NG).

Runtime switch (config file and/or env var)
 is more flexible than compile-time one
but OK let's go with compile-time option.

This one should be harmless.
I let you do it, thanks.

Eric NOULARD <erk>
Group administrator
Sat 29 Aug 2009 11:35:56 AM UTC, comment #2: 

We renamed libRTI to libRTI-NG. It seems to me now that different libraries should have different tick() behaviour. That the old libRTI should have the old tick() and the new libRTI-NG should have the new tick(). There may be more issues like this.

As an alternative, instead of introducing yet another certi specific extension, we may introduce a compile time switch that would build either libRTI or libRTI-NG with the right tick() behaviour.

What do you think?

Yes. I can do the implementation.

Petr Gotthard <gotthardp>
Group Member
Sat 29 Aug 2009 10:45:12 AM UTC, comment #1: 

I discussed this with Pierre who answer that
CERTI tick function was there before RTI-NG was
(CERTI began was born in 1996)
so that saying (like I did on the ML)
that CERTI should conforms to RTI-NG behavior
is misleading :-)
Historically RTI-NG did not follow the CERTI behavior :-)

However in order to ease transition we (at least Pierre and I)
are OK to switch CERTI default tick() function to RTI-NG behavior. This would definitely ease the RTI-NG to CERTI
transition.

However, I'd like to maintain the "old CERTI" behavior as
a new legacy compatibility function tick_once() or
tick_certi() such that if anyone cross a compatibility
issue with this default behavior change he may still
have access to the old behavior.

Petr, what do you think?
Would you like to implement the fix?

Eric NOULARD <erk>
Group administrator
Fri 28 Aug 2009 01:02:41 PM UTC, original submission:  

The RTI-NG says "The zero-argument variant of tick reads all available network traffic, then does as much processing as possible without blocking".

However, the CERTI tick() does process only 1 callback:
   __tick_kernel(RTI_FALSE, 0.0, 0.0);

I do not recommend to create any proprietary extensions. I propose to modify the tick() behaviour to conform to RTI-NG:
   __tick_kernel(RTI_TRUE, 0.0, std::numeric_limits<double>::infinity());


Petr

Petr Gotthard <gotthardp>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by gotthardp (Submitted the item)
  •  

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-27 erk StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNextRelease 3.3.3
    2009-08-31 gotthardp StatusReady For Test In Progress
    2009-08-31 erk Dependencies- bugs #27357 is dependent
    2009-08-31 gotthardp Assigned toNone gotthardp
        StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code