[sane-devel] Some thoughts on pthread support...
Gerhard Jaeger
gerhard@gjaeger.de
Wed, 15 Oct 2003 08:50:26 +0200
Hi list,
as you might remember ;-)))) I've updated the sanei_thread lib to support
pthreads and Henning worked on the test-backend to make it work correctly
with the pthreads. Here are some ideas/thoughts on that work, that might =
touch
other developers too:
- the difference between pthreads and a forked process is the process con=
text
where those two incarnations life. The function running as thread lives=
in
the same "world" where the man process lives and therefore shares its
signal "behaviour. The function running in the forked child processs no=
t!
--> Thats why we get some trouble, when terminating the thread (mostly a
reader thread) and killing its pipe to the main-process. Killing mean=
s
pthread_cancel (which is not very nice, but necessary if the reader-t=
hread
will not respond, or sleeps as in the test-backend). So killing also =
the
pipe will result in a SIGPIPE, which defaults to terminating the whol=
e
process if not handled or blocked...
Suggestion for sanei_thread: As this is almost everytime used to crea=
te
a reader process, the sanei_thread_begin
function should also block the SIGPIPE w=
hen
running in the pthread version
--> In the pthreaded version, for sanei_kill, we use the pthread_cancel
functionality, why? This is the function designed to "kill" a pthread=
=2E
We cannot simply use pthread_kill(id, SIGTERM), as this will not only=
kill
the thread, but also the whole process (remember, we live in one worl=
d).
Anyway, pthread_cancel, should be used rarely. In general, the reader
thread should be designed that way, that it ends simply by returning,
even if canceled, so it has the chance to shutdown gracefully. This=20
indeed is not necessary when running as own process, as all the clean=
up
work can be done by the OS, but this should be done, when running in
threaded envrionment. (Okay the pthreads in Linux are in fact own
processes, but only there AFAIK)....
Suggestion for reader_process: Design it that way, that the main proc=
ess
is able to cancel the process by sendi=
ng a,
let's say command, which can be detect=
ed by
the reader-process, to cause it, to
shutdown gracefully. i.e. send a SIGUS=
Rx
and handle it. So there's no need of
pthread_cancel (only if it hangs)...
Well in the end, we also have to say, that using pthreads under Linux or=20
maybe other OS that are able to handle fork correctly (I mean clone all, =
even
FS-handles), is not really necessary. But when we'd like to make SANE wor=
k
even on MacOSX or OS/2, then we should be aware of these issues.
Just my two cents (maybe a little more ;-)
Ciao
Gerhard
=20
=20