On Fri, 21 Sep 2007, Frank Hofmann wrote:
[ ... ]
> So no, that doesn't work. Although it seemed interesting.
That said, if the check can be (very) expensive, one could use:
mutex_enter(mymtx);
ddi_taskq_dispatch(system_taskq, my_trigger_func, NULL, DDI_SLEEP);
if (cv_timedwait_sig(mymtx, mycv, ddi_get_lbolt() + 1000) == 0)
signaled = TRUE;
else
signaled = FALSE;
mutex_exit(mymtx);
void my_trigger_func(void *unused)
{
mutex_enter(mymtx);
cv_broadcast(mycv);
mutex_exit(mymtx);
}
The taskq cannot proceed before timedwait_sig temporarily dropped the
mutex and that only happens shortly before it goes to sleep. So the above
actually _will_ sleep, only to be woken up again when the system finds
time to schedule the task.
Which means this method of checking is slow and expensive :(
FrankH.
>
>>
>>> 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? ;-)
>
> Even Solaris undocumented interfaces tend to be more stable than Linux
> documented ones ...
>
>
>>
>>> 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...
>
> Except it doesn't do, unfortunately.
> Sorry for the noise.
>
> Maybe the code can be reordered/rearranged so that the cv_*sig() functions
> are usable, i.e. for example a taskq- or timeout- and intr-signaled cv for
> aborting stuck transfers, so that the read/write frontends could just
> cv_wait_sig() instead of attempting to poll on the signal state. Polling
> on state never seems like a good idea, but then, ho-hum, there's good
> ideas and there's real life ...
>
> Looking at the implementation of the cv_*wait_sig() functions, the actual
> conditions under which these return zero are quite complex. It's not a
> simple check on the thread/process signal masks.
>
> I wonder whether it'd make sense to ask for inclusion of such a polling
> function into the DDI. After all, you already do have proc_signal() to
> raise one from within a driver ...
>
> FrankH.
>
>>
>> thanks, Joachim
>>
>> --
>> Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
>> phone ++49/(0)228/324 08 17 - http://www.dolphinics.com
>> _______________________________________________
>> opensolaris-code mailing list
>> [email protected]
>> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
