Joachim Worringen wrote:
> Frank Hofmann wrote:
>
>> On Fri, 21 Sep 2007, Joachim Worringen wrote:
>>
>>
>>> Greetings,
>>>
>>> while processing my driver code in user context, is there a way to check
>>> if a signal is pending for the process? I can check for the ability to
>>> receive signals using ddi_can_receive_sig(9F), and see if I was signaled
>>> while waiting on condition variable - but is there a way to "poll" for a
>>> signal?
>>>
>> This comes to mind:
>>
>> if (cv_timedwait_sig(cv, mtx, ddi_get_lbolt()) == 0)
>> /* signal pending */
>>
>> but my mind rings 'hacky' bells on seeing this ...
>>
>
> I also though of something like this, but I am not sure if you can rely
> on the signal pending condition being checked before the timeout. Should
> be like this, yes, as checking for a pending signal is cheaper then
> setting up a timeout, and makes sense also semantically (because a
> timeout can never be pending).
>
>
>> The low-level method, outside of DDI, exists of course, ISSIG() and
>> related macros ...
>>
>
> I'd like to stick with the documented interface... Otherwise, I could
> stay with Linux right away, or? ;-)
>
>
>> Why do you need to know this in a driver, how should behaviour be
>> different ?
>>
>
> I'm porting some modules from Linux that use "signal_pending(current)"
> in some places.
>
> I already managed at one place to recode so that I can omitt the
> signal_pending(); I hopefully can continue this path. Otherwise, the
> construct you proposed looks not all that hacky...
>
The only reason, I can think of, to do a signal check is because you're
waiting for something that may take a while... in which case use the
cv_wait_sig or cv_timedwait_sig API. If your process is going to run
very quickly, there is almost no reason to make it interruptible. It
adds a lot of complexity, and brings little value.
Of course, if you're doing a lot on the CPU in user context, it gets a
little stranger.... then you'd want those checks periodically. But the
only excuse I can think of for that is doing something truly CPU bound,
like crypto, in the kernel.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
