On Fri, 21 Sep 2007, 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).
Hmm, just checked the code, and of course though one would hope it'd check signal-first timeout-later, it checks timeout-passed/signal/timeout and will return -1 in the case above :( So no, that doesn't work. Although it seemed interesting. > >> 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
