Hi,
A few users have commented here:
https://gitlab.com/sane-project/backends/-/issues/153#note_1080066112
https://gitlab.com/sane-project/backends/-/issues/473#note_1080234318
...that the conversion of sanei_thread to use processes instead of
threads has effectively broken scanning on the on some platforms.
Apparently, there is a reference to a long standing issue identified in
the implementation and use of the sanei_thread API.
In particular, I think that there are a few issues:
1. There are assumptions that pthread_t is arithmetic.
2. Some backends are assuming that SANE_Pid is a pthread_t and abusing
the abstraction
3. Despite the warnings about comparing pthread_ts directly, we do have
a few instances where code is not using pthread_equal() or a
sanei_thread equivalent.
4. There is no cross-platform method for determining if a SANE_Pid is
"valid", which is where some of the above backend issues come from.
So I have tried to come up with a solution that I believe doesn't
strictly break API compatibility although because of some of the
aforementioned issues, there are breaking changes to some of the backends.
The idea is to replace the existing SANE_Pid with a structure:
typedef struct
{
SANE_Bool is_valid;
#ifdef USE_PTHREAD
pthread_t pid;
#else
int pid;
#endif
} SANE_Pid;
Because this is now a structure, invalid direct comparison of SANE_Pid
using == now raises a compile error.
Additionally, with the addition of a new is_valid flag, we can indicate
if the enclosed pid member has a valid value.
The ramifications of this internal change should be entirely confined to
sanei_thread but a few backends required some small changes.
See https://gitlab.com/sane-project/backends/-/issues/153 for some
discussion.
I have drafted up this change, although I haven't performed much in the
way of testing with machines yet (I will!) here:
https://gitlab.com/sane-project/backends/-/merge_requests/750
I accept that some 3rd-party builds might be a broken slightly by this
change, but that would surely be due to one or more of the abuses of the
API mentioned above.
I would appreciate comments on the general strategy and reviews of the code.
Cheers,
Ralph
