[sane-devel] Re: Need help porting sanei/sanei_thread.c (Rene W. Olsen)

[Rene W. Olsen]

On 2005/09/08, François Revol wrote:

>> Date: Thu, 08 Sep 2005 03:37:13 +0100
>> From: "Rene W. Olsen" <ac at rebels.com>
>> 
> 
> If SIGPIPE doesn't exist there is no reason to touch its handler :)

Good point
 
> How about...
> 
> static void
> restore_sigpipe( void )
> {
> #ifdef SIGPIPE
>    struct sigaction act;
> 
>    if( sigaction( SIGPIPE, NULL, &act ) == 0 ) {
> 
>        if( act.sa_handler == SIG_IGN ) {
>            sigemptyset( &act.sa_mask );
>            act.sa_flags   = 0;
>            act.sa_handler = SIG_DFL;
>            
>            DBG( 2, "restoring SIGPIPE to SIG_DFL\n" );
>            sigaction( SIGPIPE, &act, NULL );
>        }
>    }
> #endif
> }
> 
> Actually I wonder why it's just not 
> 
> static void
> restore_sigpipe( void )
> {
>   signal(SIGPIPE, SIG_DFL);
> }
> 
> There is no reason to use sigaction only for this.

Okey I have added #ifdef SIGPIPE
 
>> Any hint were to find some info on sigaction is welcome :D
> 
> man?
> google?
> http://www.opengroup.org/onlinepubs/007908799/xsh/sigaction.html

Thanks, I was a little tired so I dident bother to google around.

>> Next problem is `pthread_kill' what do I do when the Amiga port of
>> PThread dosent support that function?
> 
> in configure.in, add an
> AC_CHECK_FUNC(pthread_kill)
> 
> then
> 
> #ifdef HAVE_PTHREAD_KILL
>    pthread_kill(...);
> #endif

Done

> though it's probably not a good idea if you unload a sane backend with 
> a thread still running code from it...

No I'll se if it turns out to be a big problem

> How about fixing your pthread port ?

I wrote to the person thats maintains the AmigaOS4 port and he wrote

-cut-
pthread_kill isn't in the original POSIX thread API, which is why I 
didn't implement it. Besides, it's highly non-portable, and since the 
thread library is not linked with the program, it's pretty much 
impossible to include that since the shared pthread_kill wouldn't be 
able to use the static linked signal handling functions (they would 
change depending on whether clib2 or newlib is used.

Bottom line, I would suggest finding a workaround for this.... There's 
no way to include that in threads.library in a sane way...
-cut-

> I know our BeOS port is unfinished either, but I did native replacement 
> code for this.

Okey

Regards
Rene W. Olsen