Re: pthread issue.

From: George Anzinger (george@pioneer.net)
Date: Tue May 23 2000 - 12:03:22 EST


Kip Matthew Macy wrote:
>
> George Anzinger wrote:
>
> > Kip Matthew Macy wrote:
> > >
> > > Read the man page again:
> > >
> > > <snip>
> > >
> > > ASYNC-SIGNAL SAFETY
> > > The mutex functions are not async-signal safe. What this
> > > means is that they should not be called from a signal han­
> > > dler. In particular, calling pthread_mutex_lock or
> > > pthread_mutex_unlock from a signal handler may deadlock
> > > the calling thread.
> > >
> > > </snip>
> > <snip>
> >
> > Gosh, is this common or just a Linux'ism? Seems like a real drag and
> > not to easy to get around.
> >
> > George
>
> There is only a relatively small set of functions specified by posix as
> being async signal safe. From the FreeBSD sigaction man page:
>
> <snip>
> The following functions are either reentrant or not interruptible
> by signals and are async-signal safe. Therefore applications may
> invoke them, without restriction, from signal-catching functions:

Interesting phrasing. "Without restriction" seems to imply that the
problem could be eased by using some "restraint". Maybe a wrapper for
the function that turned off (masked) all signals would do the trick.
>
> Base Interfaces:
>
> _exit(), access(), alarm(), cfgetispeed(), cfgetospeed(),
> cfsetispeed(),cfsetospeed(), chdir(), chmod(), chown(),
> close(),creat(), dup(),dup2(), execle(), execve(), fcntl(),
> fork(), fpathconf(), fstat(),fsync(), getegid(), geteuid(),
> getgid(), getgroups(), getpgrp(),getpid(), getppid(),
> getuid(),kill(), link(), lseek(), mkdir(),mkfifo(),
> open(), pathconf(), pause(), pipe(), raise(), read(),
> rename(),rmdir(), setgid(), setpgid(), setsid(), setuid(),
> sigaction(),sigaddset(), sigdelset(), sigemptyset(),
> sigfillset(),sigismember(),signal(), sigpending(),
> sigprocmask(), sigsuspend(), sleep(),stat(),
> sysconf(), tcdrain(), tcflow(), tcflush(), tcgetattr(),
> ttcgetpgrp(),csendbreak(), tcsetattr(), tcsetpgrp(),
> time(), times(), umask(),
> uname(), unlink(), utime(), wait(), waitpid(), write().
>
> Realtime Interfaces:
>
> aio_error(), clock_gettime(), sigpause(), timer_getoverrun(),
> aio_return(), fdatasync(), sigqueue(), timer_gettime(),
> aio_suspend(),sem_post(), sigset(), timer_settime().
>
> All functions not in the above lists are considered to be unsafe
> with respect to signals. That is to say, the behaviour of such
> functions when called from a signal handler is undefined.
>
> </snip>
>
> The last paragraph is noteworthy.

Yeah, they dropped the "without restrictions" consideration. I seem to
recall seeing interfaces with "_reent" (or some such) appended to their
entry point names (often with an additional parameter to point at a
thread specific storage location) to get around such restrictions. The
point was to make the function re-entrant. I think its either HP or
Lynx
that did this.

<snip>

George

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:24 EST