[sane-devel] Re: pthread_cancel and MacOS X
Sun, 11 Jan 2004 19:39:02 +0100
On Sun, Jan 11, 2004 at 06:57:09PM +0100, Jaeger, Gerhard wrote:
> Henning, what do you think about changing the test-backend. As far
> as I understood, the test-backend simulates, when the reader-process
> has finished, a "hanging" backend, that is "killed" by the parent process.
> Probably we can accept a workaround only for the MacOS platform...
I think that generally there should be no OS-specific code in the
backends at all. The whole idea of sanei_thread and the other sanei_
code is to abstract the OS and hardware access.
The idea behind the "hanging" reader process is that the SANE standard
wants the backend to close the select filedescriptor at the end of the
scan. That's done by the test backend.
Some time ago we had trouble with frontends that couldn't cope with
closing the select file descriptor. This descriptor is usually a pipe
and is it not enough to close the reader process part of that pipe.
The parent process side has to be close and that's the signal for the
frontend that scanning is finished (no more data).
If the reader process doesn't hang until sane_cancel, there is a race
condition between closing both sides of the pipe. To make sure that
all frontends can cope with closing only the main process side of the
pipe, the reader process waits.
So if a frontend (or sanei_ implementation) can't cope with that,
there is usually a general problem that just don't happen that often
with other backends because most of the time the reader process
terminates too fast.
However, with threads I guess a file descriptor isn't closed after
exiting the thread (?). In this case we can ignore that problem so I
don't mind removing the endless loop if we are using threads in the
I don't know about the patch concerning sanei_thread itsself as I'm
rather clueless about threads :-)
Generally speaking, this should be fixed where it is broken. If there
are simple and not too ugly workarounds in SANE, that's ok for me. But
otherwise I guess it's "not our fault".