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.
-- Garrett
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
