[sane-devel] pthread support and MacOS X

[Gerhard Jaeger]

Hi,

On Wed, Oct 08, 2003, Henning Meier-Geinitz wrote:
>>     system-function will then be done in sanei_thread_begin. 
>> --> int sanei_thread_begin( int(callback)(void*args), void *args)
>
>Yes, that's ok I think. I've already thought about that because there
>is no way to return a status with the current setup of void
>func_to_call.

this is done in the current implementation of sanei_thread_begin()

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

Do we need options at all? You are using WMOHANG in plustek.c but if
you kill() a process and after that waitpid () doesn't return because
no process has been killed something starnge has happened. I'd assume
that can't happen.

The options-argument has been removed. 
The WNOHANG stuff I think is "historical", but I have to check this.
In the meantime, I added a function, named:
sanei_thread_get_status(), which makes internally use of the WNOHANG option

>So just using the normal (blocking) waitpid may be enough.

Think you're right there.

>Do we need to know if the process was killed or just exited? If we
>don't need to know that something like this may be enough:

>SANE_Status sanei_thread_wait (int pid, SANE_Status *child_status);

see latest implementation ;-)

>if waitpid (or pthread_join/pthread_detach) fails, return
>SANE_STATUS_INVAL (or IOERROR or whatever), otherwise SANE_STATUS_GOOD.
>
>client_status is the status of the process (WEXITSTATUS()) if it
>exited normally or SANE_STATUS_GOOD (?) if it was killed. Or, if
>necessary:
>
>SANE_Status sanei_thread_wait (int pid, SANE_Bool *killed, SANE_Status 
>*child_status);
>
>*killed = SANE_TRUE if the process was killed. But I don't think it's
>necessary.

The sanei_thread_kill function has also been changed. This function now
sends a SIGTERM signal to a child process, or in pthread environment it
calls pthread_cancel.
To send a specific signal to a child/thread, sanei_thread_sendsig() is
available...

I think this is the set of function we need. Maybe number of the can be
reduced, but for now it's possible to let every backend, that currently
uses fork, run in a pthread environment with a minimum set of changes...

The interfaces currently are not that proper, but I'd like to change this in
the near future. Maybe there are other, or some more requirements on
that thread library.

By using this sanei_thread stuff, I think the os2_readerprocess is also
obsolete, but this has to be checked by whoever...
Also whether the lib is still usable for OS/2. AFAIR, the native thread-model
of OS/2 can be used in a similar way like pthread... Maybe Yuri is able
to make the necessary changes there. It's maybe interesting to get some info
which backends are really usable on OS/2 and need the change to sanei_thread.
In the test backend there's still this os2_readerprocess, but I'd like to
remove it.

Henning, thanks for discussing this stuff, your ideas are always welcome.
Maybe there are some more of you who have some ideas...
Beat, are you on this list? Can you checkout the latest sane-backends on your
MacOS X and check the plustek-backend with pthread support on your box?
Franz, I think you can to some investigation on OS/2. Are you able to make the
test-backend work there?

Ciao,
  Gerhard