What's really wanted here, is a pthread_poll(), that takes an optional
condition variable and mutex. Then it can wake up on the condition
variable being signaled, and it can all be atomic via the mutex.
Oh well, wishful thinking for APIs that don't exist.
I hate userland programming. :-)
-- Garrett
Michael Hunter wrote:
> On Thu, 22 Feb 2007 17:39:47 -0800
> Garrett D'Amore <[EMAIL PROTECTED]> 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.
>>
>
> Whats the poll/select set have to do with aborting the actual I/O? They
> are just providing the ability to receive notification as to possible
> I/O opportunities. On Solaris I believe poll() will return if you
> close() an fd out from underneath it. Not so sure how portable that
> assumption would be.
>
> It sounds to me like the set of fds you might be interested in is
> dynamic in which case it seems like the interesting point is when you
> need to _add_ an fd to the interest set. Still, same problem. I'd
> probably end up using the pipe.
>
>
>> 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.)
>>
>
> I'm not sure about the portability of cancellation. I've used it in
> several different places but none of them are Linux. I wouldn't be
> suprised if there are implementation differences.
>
> [...]
>
> mph
>
--
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
