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
