I’ve release Libinsane 1.0.5.
The main change is the addition of an extra workaround: On Linux only, it does run all the scanner operations in a dedicated process instead of the application process.
The root of the problem is that, by default, Sane and Sane backends act as simple libraries. They run as part of the application. So when a backend crashes, corrupt the memory, or randomly close file descriptors just for fun (I’m looking at you Brother), it messes with the application itself. By running Sane and its backends in a dedicated process, the application is protected from the weird behavior of the backend.
Also, over time, some backends have shown to be more unstable when running as part of a complex application (Python3+GTK+threads for instance --> Paperwork). By running them in a dedicated process, we can expect some backends to work more reliably.
Even better, since the backend runs now in a dedicated process, I’ve been able to safely add a SIGSEGV and SIGBUS handler to get a stacktrace when a crash occurs. Since the application (Paperwork for instance) remains alive, it can log this stacktrace ! )
On Windows, with WIA2, this workaround is not required since WIA2 already takes care of running the minidrivers in a dedicated process. So things remain as before.
With TWAIN, I’m not sure whether this workaround would make sense. Anyway, the cost of porting this workaround to Windows would be prohibitive for an API that is on its way out as far as I know.
As usual, information regarding Libinsane are available at https://gitlab.gnome.org/World/OpenPaperwork/libinsane .
Detailed ChangeLog is available here: https://gitlab.gnome.org/World/OpenPaperwork/libinsane/-/blob/master/ChangeLog .