On Thu, 13 Apr 2006 15:45:22 -0700, "Jouni Malinen" <[EMAIL PROTECTED]> wrote:
> > [...] 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). I see... Thanks for explainig it. > [...] 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? I think you are taking this concept too far. Consider things like an ioctl to seek a magnetic tape N files forward, or an ioctl to flush characters to a terminal. They seem to work fine in blocking mode. And no, we do not have a generic API to expose semaphores (I suppose you did not mean SYSV IPC above :-). -- Pete - 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
