As found by Volantus/berry-spi#2 (comment) __desctruct of SpiInterface could cause problems in forks, as it might close the socket of the main process during GC of child process.
Normally I would say, that library user has to handle all side effects of forking.
But the only way of handling this, has a huge downside.
Leave everything at it is
Downside: If the process needs to be forked all SPI devices needs to be closed first and reopened after the fork started.
Remove the complete __desctruct logic
Downside: Users have the full responsibility of closing the device before loosing the object reference.
Adding special flag for disabling the __desctruct logic
A setter or flag could be added for enabling/disabling the destruct logic. Maybe the cleanest solution.
Opinions are welcome. Especially maybe of @KiNgMaR.
As found by Volantus/berry-spi#2 (comment) __desctruct of SpiInterface could cause problems in forks, as it might close the socket of the main process during GC of child process.
Normally I would say, that library user has to handle all side effects of forking.
But the only way of handling this, has a huge downside.
Leave everything at it is
Downside: If the process needs to be forked all SPI devices needs to be closed first and reopened after the fork started.
Remove the complete __desctruct logic
Downside: Users have the full responsibility of closing the device before loosing the object reference.
Adding special flag for disabling the __desctruct logic
A setter or flag could be added for enabling/disabling the destruct logic. Maybe the cleanest solution.
Opinions are welcome. Especially maybe of @KiNgMaR.