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.
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.
>
> 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.
mph
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
