[sane-devel] OS/2 support in backends

[Henning Meier-Geinitz]

Hi,

On Mon, Oct 13, 2003 at 10:06:36AM +0200, Gerhard Jaeger wrote:
> thanks to Franz Bakan, I've managed to fix at least the sanei_thread support
> for OS/2 - the test-backend works on that platform.
> While searching through the backends, I noticed, that at least three other
> backends (avision, mustek and hp) support OS/2 by defining a
> os2_readerprocess. This is no longer necessary. (Peter Kirchgessner, had
> already confirmed, that he will change his HP backend code...)
> Please remove the os2_readerprocess and modify your code maybe that
> way like it's done in the test backend. As soon, as every os2_readerprocess
> function has disappeared, I will remove the porting stuff from sanei_thread.h.

I'm currently porting the mustek backend. While compilation and fork
support (default) works on Linux using pthread doesn't work completely
yet. I can scan but cancelling the scan freezes the application.

I'm getting similar results with the test backend: Compile it with
thread support and start a preview. There is a 10 second delay until
the preview is finished. That's the delay at the end of the
reader_process. But the reader_process should have benn immediately
stopped by pthread_cancel(), shouldn't it?

You have reduced the 1000 seconds to 10 seconds. The
delay is there intentionally. In fact, the reader_process should never
stop until it's killed by the main thread/process. The reason is that
first the parent part of the pipe must be closed, not the child side.
See SANE standard for sane_get_select_fd. So it would be even more
correct to write something like "while (SANE_TRUE) sleep (1);"

Maybe something is wrong with pthread_cancel()?

Ok, the reason seems to be the blocking of all signals but sigterm in
test.c. It works, if I don't do this. Maybe pthread_cancel() uses one
of those signals?

I guess we don't need to block the signals for the test backend. But
at least for mustek, I need the signal blocking and the signal
handler, otherwise the scanner may be left in a confused state if the
scan is cancelled. Maybe I'll just block all siganls while
reading/writing and enable all after that again. And the signal
handler is called for all signals.

Do you know which signal is used by pthread_cancel()?

Bye,
  Henning