Hi, 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 test backend. 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". Bye, Henning
