[sane-devel] pthread support and MacOS X
Mon, 6 Oct 2003 08:28:22 +0200
On Sonntag, 5. Oktober 2003 23:54, Henning Meier-Geinitz wrote:
> 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=
> > the Plustek backend, so that it will use threading instead of forking=
> > 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:
> - 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,=
could be done better. The first implementation (OS/2) only replaces forks=
the sanei_thread functions and at least this encapsulated reader_process.=
second approach, encapsulates the pthread stuff... Regardless, what we're
doing, the backends must be modified from the fork stuff to the sanei_thr=
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
> - 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=
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=
> - 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...