You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: