Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning

[Stephen Hemminger <shemminger@osdl.org>]

On Thu, 13 Apr 2006 15:45:22 -0700
"Jouni Malinen" <jkm@devicescape.com> wrote:

> On Thu, Apr 13, 2006 at 03:28:53PM -0700, Pete Zaitcev wrote:
> > On Thu, 13 Apr 2006 09:00:51 -0700, "Jouni Malinen" <jkm@devicescape.com> 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?
> 

Sounds like you want a message interface like netlink, not ioctl's.