On Wed, 23 Jul 2008, Ivo van Doorn wrote: > On Wednesday 23 July 2008, Henrique de Moraes Holschuh wrote: > > This is my next batch of rfkill changes. They add features and address > > some shortcomings of rfkill-input, mostly. > > > > Please comment. One thing that is bothering me in the last patch is > > what happens during suspend/resume to pending delayed rfkill state > > changes. Are pending scheduled jobs executed, cancelled, or frozen to > > fire up when the system resumes itself? > > When using the kernel workqueue, I *think* they are frozen until the system > resumes. When using a private workqueue you should use the freezable > workqueue allocation. > > But in this case you are using the kernel workqueue, so I assume it is > scheduled untill after resume. I will look into handling that in the next version, then. Or as a separate patch. I wonder if we should switch to a private workqueue? We are not being exactly lightweight users of schedule_foo in rfkill-input, and I'd really hate to hang the main workqueue if something in rfkill/rfkill-input decides to deadlock. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
