On Thu, Apr 13, 2006 at 03:28:53PM -0700, Pete Zaitcev wrote: > On Thu, 13 Apr 2006 09:00:51 -0700, "Jouni Malinen" <[EMAIL PROTECTED]> wrote: > > > That could be blocking an ioctl call for couple of seconds > > and would be quite horrible for single threaded programs. > > I would say that waiting for couple of seconds in the kernel would > be quite wonderful for single threaded programs, when you consider > the alternative. I can guess now what your concern is, even though > you failed to articulate it: a single-threaded GUI application, > which cannot respond to events when blocked in getting scan results. > If that's the case, we should be looking at having both blocking > and non-blocking calls to fetch scan results.
No, my main concern was single-threaded design in wpa_suppliant.. If the ioctl call is blocking, I would need to create a new (well, the first additional) thread just for this use. Without that, the blocking call would also block all control interface commands (interaction with external programs) and controlling of other interfaces (if more than one is used). > > [...] but what if some other program were > > to request a new scan between the completion event and the attempt to > > read the previous scan results.. > > I do not see how this is relevant. That would make the application wait even if it properly waited for the scan complete event before reading the scan result. If the get-results call is blocking, the single-threaded application simply don't have any easy way of getting the results while being able to do something else while waiting for the scan to complete. Furthermore, blocking ioctl handlers is not really something I would like to see in the kernel.. Aren't there some locks/semaphores/etc. kept for some cases? -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
