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
Hi,
On Mon, Oct 13, 2003 at 04:30:42PM +0200, Erik Inge Bolsø 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 Thre
On Mon, 13 Oct 2003, Henning Meier-Geinitz wrote:
>Maybe something is wrong with pthread_cancel()?
>
>Ok, the reason seems to be the blocking of all signals but sigterm in
>test.c. It works, if I don't do this. Maybe pthread_cancel() uses one
>of those signals?
>
>I guess we don't need to block the
Hi,
On Mon, Oct 13, 2003 at 10:06:36AM +0200, Gerhard Jaeger wrote:
> thanks to Franz Bakan, I've managed to fix at least the sanei_thread support
> for OS/2 - the test-backend works on that platform.
> While searching through the backends, I noticed, that at least three other
> backends (avision,
Hi list,
thanks to Franz Bakan, I've managed to fix at least the sanei_thread supp=
ort
for OS/2 - the test-backend works on that platform.
While searching through the backends, I noticed, that at least three othe=
r
backends (avision, mustek and hp) support OS/2 by defining a
os2_readerprocess. T
