[sane-devel] pthread support and MacOS X

[Gerhard Jaeger]

On Sonntag, 5. Oktober 2003 23:54, Henning Meier-Geinitz wrote:
> Hi,
>
> On Sun, Oct 05, 2003 at 06:16:12PM +0200, Jaeger, Gerhard wrote:
> > I've currently added pthread support to the sanei_thread lib and chan=
ged
> > the Plustek backend, so that it will use threading instead of forking=
 on
> > MacOS X. Could somebody please test this?
> > Also the detection of pthreads is not correct, please test also...
>
> Just some quick comments, I'll test more during the next few days:

Okay ;-)

> - I think it's good to have support for different types of fork/thread
>   whatever. However, I'd like to have that completely in sanei_thread
>   (or wherever). So I'd call sanei_thread_begin in my backend and
>   don't care if it expands to pthreads, OS/2 threads or fork. This
>   means some limitations (e.g. only one parameter for OS/2?) and we
>   have to check that the reader processes work with both threads and
>   processes. Otherwise we must have #ifdefs for 3 platforms in our
>   backends as both OS/2 and MacOS need special care now. MacOSX needs
>   sanei_thread_whatever, OS/2 needs fork() and a encapsulated
>   reader_process and everything else needs fork() only.

You're right on that. I'll see what can be done, the current impact on
modifications within a backend that uses fork is rather low, but I agree,=
 it
could be done better. The first implementation (OS/2) only replaces forks=
 by
the sanei_thread functions and at least this encapsulated reader_process.=
 The
second approach, encapsulates the pthread stuff... Regardless, what we're
doing, the backends must be modified from the fork stuff to the sanei_thr=
ead
stuff AND the sanei_thread lib must handle fork/pthread itself...

Any other comments? I mean we can also decide to skip this pthread stuff
completely!

>
> - The docu in include/sane/sanei_thread.h should be updated (but only
>   when we are sure if we keep the current implementation)

That's quite clear, this highly depends on the backend developers. If the=
y
like to use the sanei_thread functionality or not.....

>
> - SANE_CHECK_PTHREAD must go into acinclude.m4. aclocal.m4 is
>   generated automatically from acinclude.m4 when you run "aclocal".
>   (After that run autoheader and autoconf). Otherwise it would be
>   deleted by the next run of aclocal.

Okay, these checks where my first trial to understand what the autoconf s=
tuff
does....

>
> - Linking fails on Free- and OpenBSD. I had only a quick look
>   but I think it's because they don't have a libpthread but pthread.h.
>   Before adding -lpthread you should check if the lib is available
>   (not only a header). Maybe you should check for the header first and
>   then if one of the pthread functions is available (in libc). If it
>   isn't, try if it's available in libpthread and link that lib.

That's what I expected...

>
> - I'm not sure if we should use threads by default (link to
>   libpthread) or only on MacOS X. Maybe that should be a configure
>   option (--enable-pthreads: default yes on MAcOS, no everwhere else)?

Yeap, fully agreed.

> There are other compilation/linking problems on other platforms but
> they may not be related to pthread. I'll look later.

Please keep me/us informed...

Ciao
  Gerhard