[sane-devel] sanei_thread

[Ralph Little]

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