[sane-devel] pthread support and MacOS X

[Gerhard Jaeger]

Hi,

On Dienstag, 7. Oktober 2003 13:29, Henning Meier-Geinitz wrote:
> The limitation is that only one parameter can be used for the
> forked/threaded process?

Yeap, that's life ;-)

No, I mean this is no real problem....
Currently I see two things that has to be solved:
1.) the interface to sanei_thread_begin
2.) the waitpid stuff

1.) I'd like to change the interface of the function to be called in the
    forked process to: int func_to_call( void*). The adaption to the different
    system-function will then be done in sanei_thread_begin. 
--> int sanei_thread_begin( int(callback)(void*args), void *args)


2.) waitpid: it's necessary to remove the specific macros WIF* etc from
    the backend. Therefore it's also necessary to define one common
    behaviour of sanei_thread_waitpid, regarding the return values and the
    blocking of this call. Maybe the function should also be renamed to
    show that it not only reflects waitpid functionality....

Any comments?


>
> What about waitpid? Do I have to rewrite code like that (from mustek.c):

Probably yes - see above. But I think this is not a big deal, because we have
only 5 backends which use this (grep WIF backend/*.c), two Plusteks (my job)
artec_eplus48 (based on the Plustek code), hp, mustek and test (up to me to
change it)....

> I guess #include <sys/wait.h> should be added to sanei_thread.h? Or to
> the individual backends?

Hmpf, okay, I've forgotten that...

>
> > I've also updated the tests in the configure script. You'll find the
> > switch --enable-fork-process, with is used to override the default
> > settings for pthread/fork usage. The default is: use pthread on Darwin
> > (if available), else use fork.
>
> That's good. I've modified the description a bit:
>
>   --enable-fork-process   use fork instead of pthread (default=no for MacOS
> X, yes for everything else)

Okay, great....

> I've also moved the message about wether pthread is beeing used to the
> end of the tests so the user knows if it's really used.

Good idea.

>
> Using threads on *BSD still doesn't work because the pthread*
> functions seem to be in libc. I've changed the code in CVS to first
> check if libpthread exists. This test will add -pthread to LIBS if the
> lib has been found. After that, all the necessary pthread_* functions
> are tested. If any of them isn't found, use_pthread is set to no.
> At the end of the test the macro USE_PTHREAD is defined if
> use_pthreads is yes. So any test in the source code should be for
> #ifdef USE_PTHREAD.

Okay, no problem

> It compiles for me now on most tested platforms (after adding the
> include to plustek.c) with and without threads. I can't test MacOS X
> or OS/2 however.

OS/2 support may need some work, but I don't know which backends
are really affected, maybe the changes are trivila, in the end all OS/2
dependent stuff should be skipped in the backends...

> On two platforms the loader complains about a missing libgcc_s but I
> think that's a local problem.
>
> OpenBSD 386 complained about a missing symbol _sanei_thread_init. I
> think that's because sanei_thread.lo was missing in the list of files
> to link to if the backends are preloaded. Fixed in CVS.

Okay.

> > The migration to this sanei_thread stuff is not complete now, but if
> > nobody has objections on that, I'd like to adapt the test-backend, to
> > show the usage.
>
> Please go ahead.

On its way ;-)

Cheers
  Gerhard