James Carlson wrote: > Could the original poster please go into more design-level detail > about exactly _why_ polling for a signal would make sense? I > understand that you're porting a Linux driver, and I understand that > Linux has this (mis)feature in its kernel. > > Simply doing the same on Solaris seems like the path of least > resistance, but I'm not sure it's right. At a slightly wild guess, it > sounds like the driver is trying to work around some other defect, > such as holding mutexes for a "long time" to synchronize threads, > rather than using condition variables, or some other synchronization- > related shortcoming. > > I'd prefer not to see a "poll for pending signal" DDI function until > there's some clear explanation of how the current signal-taking > functions are themselves insufficient.
Yes, my orignal motivation was to do a quick-as-possible working port - which does not mean I would tolerate a dirty port. We maintain a kernel-abstraction layer, and adding a check-for-signal function for Solaris would support this approach. I'll suspend this for now (see below). The current Linux driver is not polling for signals in the sense of looping until there is a signal, but just checks on certain occasions if there is a signal. As mentioned in my reply, I already could remove such a check while still making sure that the process will react to signals. In this case, it was just a matter of storing and interpreting result codes consistently. I agree that by design, the "running" code sections should not need to check for signals, but only "sleeping" code sections. I hope I can handle the remaining occurences of signal_pending() in the same way. Thanks everyone for the feedback! 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
