Quote:
Originally posted by shaver
I'll admit, for starters, that I'm not sure exactly what the pathology of this is, but I have a case where an application -- which uses Ice facilities, but not the communicator -- works if I inherit from LocalObject, but not if I inherit from Object.
|
I just tried your example with RH8 (sorry, I don't have RH9 available right now) and gcc 3.2. With that, it works as expected (prints "TimedEventService started" and "TimeEventService stopped").
Quote:
Specifically, it seems that presence of a IceUtil::Handle hangs my test app -- in what I had previously believed was a totally unrelated place -- if the template parameter is of a class that derives from Ice::Object.
|
I can't reproduce the problem, so what follows is largely speculation...
Ice::Object is derived from IceUtil::GCShared. In turn, GCShared hooks into the data structures for the garbage collector. The collector is initialized the first time you call Ice::initialize(). If you do not create any communicator in your process, the collector's data structures are not initialized.
I suspect what is happening is that, due to some difference in static initialization order between RH8 and RH9 (or due to differences in the way you linked your code to the way I linked it), something isn't initialized, causing the problem you are seeing. One way to test this would be to simply add a call to create a communicator to your code (and, of course, properly destroy that communicator again). If that makes the problem go away, we have at least identified the cause.
Having said all this, it seems a bit strange to want to use Ice::Object without also creating at least one communciator. Ice::Object is the base of all non-local interfaces and classes and, as such, contains fundamental hooks into the Ice run time, such as keeping track of objects for garbage collection and marshaling of objects. If you don't create a communicator, you cannot possibly marshal anything, so that begs the question of why you would want to derive something from Ice::Object without also creating a communicator
Or, to put it differently, the first call to Ice::initialize() initializes the Ice run time and, without having made such a call, you cannot expect things to work that interface with the Ice run time (such as using a remotable object).
Could you let me know what happens if you instantiate a communicator please? Also, taking a core dump of the hung process and then getting a stack trace of all active threads would be useful. Once we know what causes the problem, I'll certainly try and see if we can come up with a way to avoid the problem you are seeing.
Cheers,
Michi.