Reconsider Dispose pattern across devices

[krwq]

Multiple devices take SpiDevice/I2cDevice in the constructor and then dispose it later. We should reconsider if this is good approach and if disposing is always expected. Some alternatives:

• do not dispose the device and let the caller dispose it instead
• take bool flag (i.e. shouldDispose) and let the caller pick what they want

[joperezr]

Instead of taking a flag, I would rather have a bool shouldDispose property that would be defaulted to true, but you could set otherwise if needed.

[Frankenslag]

I like the 'shouldDispose' property... Certainly something is needed as multiple device bindings can use the same GPIO controller for example. I am not sure that it should be defaulted as true as I would generally prefer the 'caller dispose' model but I am undecided if it would be a good idea to change what seems to be happening already.

[krwq]

I'm personally in favor of not disposing at all (move the responsibility to the caller) and where Dispose ends up being empty (presumably most of the devices) I'd just drop interface implementation to make it clearer that we do not Dispose anything

[Gnbrkm41]

+1 to not disposing at all. Personally I think people will dispose of both the original disposable and the type holding the disposable anyway (that's what I do at least 😛 )

using (Stream stream = File.Open())
using (StreamReader reader = new StreamReader(stream))
{
    // Some nice codes come here
}

Like this. usings make them pretty easy to do if one has to dispose of both instances anyway.

I would rather have a bool shouldDispose property that would be defaulted to true

But I think this is a nice idea as well. Giving them some choice is better than no choice, I guess.

[joperezr]

I think people will dispose of both the original disposable and the type holding the disposable anyway

If they do this, it should be fine with the way we are writing the bindings and our devices, because calling dispose twice should just be a no-op the second time. I'd still argue that disposing them being the default would be better, since I believe that most of the time the I2c or Spi device won't be used other than to initialize the device binding, so it should be ok to assume that we call dispose. I do agree however, that we should provide a way for people to change a setting in order to not dispose when the main device binding gets disposed, for those very few cases where people would want this.

[krwq]

I believe that most of the time the I2c or Spi device won't be used other than to initialize the device binding

@joperezr I'd disagree - for simple tests of devices that will be true but any larger/commercial app will likely use multiple SPI devices and will probably try to reuse the same instance.

Most of the time device bindings don't dispose anything else than SPI/I2C device which suggests perhaps user should just dispose SPI/I2C directly and that devices should not implement dispose pattern

[Frankenslag]

I’m a novice here but I think we need to look at why Dispose is there and as I understand it then it is to release unmanaged resources (file handles for example) when the object is no longer required. So an object should dispose

• unmanaged members. Created within the object.
• managed members that are created within the object and they themselves contain managed resources and thus implement IDispose

Those items passed in from the outside are not created inside and thus should be disposed outside of the object in my opinion.

I actually don’t like the way that stream reader does things because it needs you to actually read the documentation to understand the dispose pattern.

I suppose I would be happy to have a parameter to specify the behaviour but I feel that the default should be to not dispose and then if you really want to get rid of the managed resources in a non explicit way then you can.

‘ sorry if this is rambling but it’s late here.....

[krwq]

To sum up this thread after talking to @tarekgh and @joperezr:

• I2cDevice and SpiDevice are bound to specific devices: (for I2C we talk to specific devices on specific addresses and for SPI we got specific CS pin assigned to specific device) which means one instance per one device instance
• GpioController can be used by multiple devices at the same time independently

Given that I think lifetime of SpiDevice/I2cDevice should finish with the device:

• always dispose
• optionally have a way of opting-out of disposing - need justified use-case
• might be a good idea to provide default device

For GpioController:

• devices should not dispose it by default
• there must be an option of opting-out if default is different
• might be a good idea to provide default controller

what do you think?

[joperezr]

That sounds good to me except for one caveat. GpioController's suggestion would be to always try to create and dispose within the code of the binding, since there is really no use/advantage of passing one in in the constructor. This eliminates the whole ownership problem, and it also allows you to still have a GpioController object outside of the binding's code.

[krwq]

@joperezr what about GPIO expanders such as i.e. https://github.com/dotnet/iot/tree/master/src/devices/Pca95x4? I wouldn't expect GpioController to ever get disposed and if you don't allow passing one in the constructor you cannot make i.e. character LCDs to work on expander