[sane-devel] Some thoughts on pthread support...

[Gerhard Jaeger]

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