Garrett D'Amore wrote:
Michael Hunter wrote:
On Wed, 21 Feb 2007 08:40:46 -0800
Garrett D'Amore <[EMAIL PROTECTED]> wrote:
[...]
I have used pthread_kill() to send a signal to interrupt a call to
poll(), in another thread. (Basically, the problem I had run into, was
that I couldn't figure out how to use a condvar to wake up a thread that
was sleeping waiting for IO. In this particular case the poll was on a
file descriptor associated with a USB device.)
Why do you need to wakeup that thread? Once you start using MT to
manage asyncronous IO you probably shouldn't attempt to do much
processing in that thread. Get the IO. Queue it onto some sort of
work queue and go back to waiting for IO.
I need to be able to _abort_ the IO in response to something happening
in another thread. Possibly I could use cancellation, but (and I feel a
little ashamed here) I'm a bit ignorant of cancellation, and I had
always been lead to believe it was still immature. (In the particular
case in question, the code has to run on Linux. Yech.)
Use the technique mws talks about to steer all of your signals to a
specific thread and deal with them there. A nice side benefit is that
changing signals from an asycronous event to a sycrnonous one should
simplify your application.
Not really. I'm only using a signal to "abort the current operation"
(or rather to signal that I want poll to exit.)
So my code basically includes registering a "no-op" signal handler, but
that gets me out of poll() with EINTR, which I can detect and then treat
as a way to exit the loop.
I considered that whole approach very ugly, and regretted using this
approach. What I had wished for at the time, was a way to provide a
condvar as an alternate way to wake up a thread sitting in poll(). In
retrospect, I suppose another approach would have been to use a pipe()
and signal it by writing to the pipe (then the thread could add the read
side of the pipe to the list of fd's it was poll()'ing for.)
Thats one way to go about it. But it seems like you shouldn't have to
if you organize your application along the lines mentioned above.
Again, look at what I'm trying to achieve -- I need to abort out of
poll(). That's all. The signal handler itself is an empty code block.
:-) And I needed to do this on Linux and NetBSD, as well as on Solaris.
The easy, portable and simple way of doing this that is not racy is to
use a pipe; the signal handler writes the info into the pipe and wakes
up the poll call.
Another way of doing this is to use pselect() and have it be the only
thread that will take delivery of the signal of interest. Not all
systems support pselect yet.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
