[sane-devel] OS/2 support in backends

[Jaeger, Gerhard]

Hi,

I had a closer look at the pthread implementation in glibc 2.2.5.
Readme the says:
- The current implementation uses the two signals SIGUSR1 and SIGUSR2,
  so user-level code cannot employ them. Ideally, there should be two
  signals reserved for this library. One signal is used for restarting
  threads blocked on mutexes or conditions; the other is for thread
  cancellation.

  *** This is not anymore true when the application runs on a kernel
      newer than approximately 2.1.60.

And the pthread.c implementation tells us:
ifndef __SIGRTMIN
static int current_rtmin =3D -1;
static int current_rtmax =3D -1;
int __pthread_sig_restart =3D SIGUSR1;
int __pthread_sig_cancel =3D SIGUSR2;
int __pthread_sig_debug;
#else
static int current_rtmin;
static int current_rtmax;

#if __SIGRTMAX - __SIGRTMIN >=3D 3
int __pthread_sig_restart =3D __SIGRTMIN;
int __pthread_sig_cancel =3D __SIGRTMIN + 1;
int __pthread_sig_debug =3D __SIGRTMIN + 2;
#else
int __pthread_sig_restart =3D SIGUSR1;
int __pthread_sig_cancel =3D SIGUSR2;
int __pthread_sig_debug;
#endif

So, when checking for _SIGRTMAX and _SIGRTMIN we find=20
(on a glibc 2.2.x) 64 and 32 --> SIGUSR1 and 2 are not used.
CANCEL uses the "realtime" signal 33.

The pthreads on Linux seem to be rather crappy concerning the
comliance to POSIX standard esp. regarding the signal handling...

Anyway, I'll check the sanei_thread concerning the pthread_cancel
again maybe there are some better solutions...

Ciao,
  Gerhard


On Montag, 13. Oktober 2003 20:04, Henning Meier-Geinitz wrote:
> Hi,
>
> On Mon, Oct 13, 2003 at 04:30:42PM +0200, Erik Inge Bols=F8 wrote:
> > >Do you know which signal is used by pthread_cancel()?
> >
> > "006 Topic: Conflicts between ISO/IEC 9945 (POSIX) and the Linux
> >  007 Standard Base.  "
> >
> > http://www.opengroup.org/personal/ajosey/tr28-07-2003.txt
> >
> > "225 Threaded applications cannot use SIGUSR1 or SIGUSR2."
> >
> > So I'd assume it is one of those.
>
> I tried to unblock SIGUSR1 and SIGUSR2 but that didn't work. So I now
> block only SIGPIPE. For me the test backend now works with both
> threads and forking. But I haven't tested on MacOS X and OS/2.
>
> Bye,
>   Henning
>