Create C# threads as background threads?

[bpolivka]

The advantage of having a Dispose() method would be that there are a lot of component management frameworks that can take advantage of IDisposable objects.

As I mentioned above, our libraries don't expose Ice directly to the client applications. Many of the apps were initially built as fat clients, and are being migrated to a service-based architecture, so we are trying to integrate Ice with as little impact on the clients as possible. One way we have achived this is by using a component container such as the Windsor MicroKernel (www.castleproject.org) to allow different subsystems to create and register components in a container which is under the application's control. The application doesn't know what is in the container. It just knows that before it exits, it has to Dispose() of the container, which in turn will Dispose() of any IDisposable objects inside of itself. Each of these libraries that uses Ice retrieves its Communicator from the container (the container can be configured to create it on first request), and the Communicator gets destroyed when the app Dispose()s of the container.

However, due to the fact that Communicator doesn't implement IDisposable, it can't directly take advantage of this. We have to wrap it in a thin wrapper class that does implement IDisposable, which in turn calls calls destroy(). If Communicator implement IDisposable directly, we wouldn't need this wrapper class.

The lack of IDisposable is far from a showstopper and not a big deal at all. It is just a very minor inconvenience.

Thanks,
Brett

[bpolivka]

Originally Posted by rdilipk

"Oops, yes, you are right. It's not clear to me what adding a Dispose() method would achieve then though. In effect, it would just be an alias for Communicator.destroy(). Who would call the Dispose() method (if not the application)? Or, to put it differently, if the application doesn't call destroy(), would it be any more likely to call Dispose?"

Even the application forgets to call Dispose, the communicator's finalizer code will call Dispose() subject to some boolean checks.

Only if the finalizer was coded to call Dispose(), which is not a requirement.

[michi]

On balance, I think that adding a Dispose() to the communicator isn't worth it. Because much of the Communicator code is generated from Slice, the only way to add this would be to add another metadata directive. And the payback for the effort is too small to make this worthwhile, I think. As you say, it's easy enough to create a wrapper class for those application that want to hide the Ice run time entirely.

Cheers,

Michi.

[bpolivka]

I hadn't thought about the fact that the Communicator was generated from Slice. I totally agree that it's not worth adding a metadata directive just to get this feature.

Thanks for all of your time,
Brett

[michi]

For Ice for C#/VB 3.2, the Ice run time threads will be created as background threads.

Cheers,

Michi.