Questions on the service implementation in Ice 1.3

[stephan]

Dear forum,

The thing I've been waiting for the most was the service implementation in the new version.
It's a rather elegant implementation, so thanks a lot!

What I tried at first was an implementation independent of Ice, i.e. simply writing some random stuff to a file.
What I discovered was that, when I compiled the program in debug mode (VS 7.0), I get an error _CrtCheckMemory(), i.e. in the malloc debugger. I hope that this error isn't created by me and you'll be able to reproduce it. If not, I would re-create my simple example.
btw: When compiling in release mode, everything works really smooth!

An other question that arised when taking a look at the service implementation: Before I was using the standard Ice::Application interface and had a while() loop (checking for interrupted() periodically) which called some functions on my server object which need to be called periodically as well. As I now only have a start() function I can overwrite and no run() function, what is your suggestion for doing periodic calls to an object from within a service? I created a separate thread in start() which does the job for me but I asked myself whether you have a better idea!

regs,

Stephan

P.S.: One suggestion for the next releases: Can't you please implement two pure virtual functions to the interface of Ice::Service named serviceLabel() and serviceName() which need to be overwritten for implementations? This would simplify the call to
myservice.exe --install "servicelabel"
to
myservice.exe --install
since the name of the service is 'known' by the implementation!
This would be similar to the implementation that Trolltech chose within the Qt solutions library (http://doc.trolltech.com/solutions/qtservice/qtservice.html )

[mes]

Hi Stephan,

Originally posted by stephan
The thing I've been waiting for the most was the service implementation in the new version.
It's a rather elegant implementation, so thanks a lot!

Thanks!

What I tried at first was an implementation independent of Ice, i.e. simply writing some random stuff to a file.
What I discovered was that, when I compiled the program in debug mode (VS 7.0), I get an error _CrtCheckMemory(), i.e. in the malloc debugger. I hope that this error isn't created by me and you'll be able to reproduce it. If not, I would re-create my simple example.
btw: When compiling in release mode, everything works really smooth!

This is the expected result if you try mixing code built using the debug and release configurations.

An other question that arised when taking a look at the service implementation: Before I was using the standard Ice::Application interface and had a while() loop (checking for interrupted() periodically) which called some functions on my server object which need to be called periodically as well. As I now only have a start() function I can overwrite and no run() function, what is your suggestion for doing periodic calls to an object from within a service? I created a separate thread in start() which does the job for me but I asked myself whether you have a better idea!

That sounds like a good approach to me.

P.S.: One suggestion for the next releases: Can't you please implement two pure virtual functions to the interface of Ice::Service named serviceLabel() and serviceName() which need to be overwritten for implementations? This would simplify the call to
myservice.exe --install "servicelabel"
to
myservice.exe --install
since the name of the service is 'known' by the implementation!
This would be similar to the implementation that Trolltech chose within the Qt solutions library (http://doc.trolltech.com/solutions/qtservice/qtservice.html )

Thanks for the suggestion, we'll probably do something similar for the next release.

Take care,
- Mark

[stephan]

Hey!

Originally posted by mes

This is the expected result if you try mixing code built using the debug and release configurations.

Yes that was what I thought in the first place. But I'm linking against iced.lib/ iceUtild.lib (I installed the prebuild VS7.0 package) in my VS debug configuration. So this should be clean.

regs,

Stephan

[bernard]

Hi Stephan,

/MD vs /MDd is more correct than release vs debug.

Since you're linking with the *d.lib Ice libraries, check that
Project->Properties->C/C++/Code Generation: Runtime Library is 'Multi-threaded Debug DLL (/MDd)'.

Also, if you are using icebox, the /MDd icebox is in %ICE_HOME%/bin/debug.

Cheers,
Bernard

[stephan]

/MD vs /MDd is more correct than release vs debug.

Sorry for the inprecision. I used /MDd.
However, in the meantime I probably discovered where the error comes from. I did a service implementation from scratch which almost worked. But as soon I created a separate thread where I initialized a new communicator, I received the malloc debugger error.

But the problem doesn't seem to come from the malloc debugger or ICE itself but rather from what I coded:


int argc = 0;
char** argv = 0;

Ice::CommunicatorPtr comm = Ice::initialize(argc, argv);


If I set argc = 1 and initialize argv, everything works well :-)

What I would like to suggest is to implement a check for this. I think this would make a lot of sense because I don't have (and don't need....) argc and argv my separate thread.

regs,

Stephan

[mes]

Hi Stephan,

Can you provide a simple example that reproduces this problem? I wasn't able to reproduce it.

Out of curiosity, why do you need to create another communicator?

- Mark

[stephan]

Hi!

Out of curiosity, why do you need to create another communicator?

hmm. Sorry for my nescience but is it allowed to share a single communicator between two threads, i.e. to pass a CommunicatorPtr to the thread?! I thought it would be cleaner to create a separate communicator handle in each thread?

regs,

Stephan

[marc]

Ice is fully thread-safe, meaning that you can share everything between threads, not just the communicator.

You definitely should share the communicator between threads, otherwise each thread will use its own set of outgoing connections.