Hi,

On Tue, Oct 07, 2003 at 10:08:27AM +0200, Gerhard Jaeger wrote:
> I've done some more changes to the sanei_thread library:
> - supports either fork or pthread stuff

Nice!

The limitation is that only one parameter can be used for the
forked/threaded process?

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

      pid = waitpid (s->reader_pid, &exit_status, 0);
      if (pid < 0)
      {
        DBG (1, "do_stop: waitpid failed, already terminated? (%s)\n",
               strerror (errno));
               }
      else if (WIFEXITED (exit_status))
      {
        DBG (2, "do_stop: reader process terminated with status %s\n",
               sane_strstatus (WEXITSTATUS (exit_status)));
                 if (status != SANE_STATUS_CANCELLED 
                       && WEXITSTATUS (exit_status) != SANE_STATUS_GOOD)
                           status = WEXITSTATUS (exit_status);
                           }
      else if (WIFSIGNALED (status))
      {
        DBG (2, "do_stop: reader process was terminated by signal %d\n",
               WTERMSIG (exit_status));
                 if (WTERMSIG (exit_status) != 15)
                     status = SANE_STATUS_IO_ERROR;
                     }
      else
      DBG (1, "do_stop: reader process terminated by unknown reason\n");      

I.e. does WIFEXITED and co. have any meaning for pthreads?

*BSD still doesn't work. This time the reason is different:

plustek-usb.c: In function usb_normFileName':
plustek-usb.c:134: warning: value computed is not used
plustek-usb.c:135: warning: value computed is not used
plustek.c: In function getReaderProcessExitCode':
plustek.c:354: WNOHANG' undeclared (first use in this function)
plustek.c:354: (Each undeclared identifier is reported only once
plustek.c:354: for each function it appears in.)
plustek.c:360: warning: implicit declaration of function WIFEXITED'
plustek.c:362: warning: implicit declaration of function WEXITSTATUS'
plustek.c:367: warning: implicit declaration of function WIFSIGNALED'
plustek.c:372: warning: implicit declaration of function WTERMSIG'
plustek.c: In function sane_plustek_get_devices':
plustek.c:1403: warning: cast discards qualifiers from pointer target type
gmake[1]: *** [plustek.lo] Error 1

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

> 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)
                          

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.
                          
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.

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.

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.
                          
> 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. 

Bye,
  Henning

Reply via email to