Date: Sat, 29 Sep 2001 11:18:18 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@vigrid.com> Cc: Alfred Perlstein <bright@mu.org>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG Subject: Re: KSE next steps... Message-ID: <3BB6106A.A44644BB@mindspring.com> References: <Pine.SUN.3.91.1010928074716.29490A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: [ ... pthread_kill ... ] > Think of this as kill() on a process; it shouldn't be too different. > If PCATCH is specified in the tsleep, then it is terminated immediately, > otherwise it just remains pending until (and if) it is checked at a > later point in time. Regardless of whether PCATCH is specified, the > thread never returns to userland. The UTS is notified through an > upcall in the same way that it would be if a thread blocked (but with > a different completion status). You need to read the manual page for pthread_kill(3P). Minimally, #include <signal.h> int pthread_kill(pthread_t thread, int sig); ...meaning that you can send _any_ signal, not just "SIGINT". The delivery is to a specific thread. This pretty much means triggering the EINTR cancellation, but doing the delivery in user space to a particular thread. The cancellation aspect assumes, of course, that SA_RESTART isn't specified (and/or siginterrupt(2) wasn't called). AIX has a nice brokeness in pthread_signal(3P), which results in MySQL and other programs which use it having a tough time. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BB6106A.A44644BB>