DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2029 Version: 1.3-current After reading some more docs about the winsock functions WSAAsyncSelect() [1] and select() [2], I'm not sure, if implementing WSAAsyncSelect() would be a good idea, because: (1) According to [1], "The WSAAsyncSelect function automatically sets socket s to nonblocking mode, regardless of the value of lEvent.". This would change the socket behavior in the user's application, maybe unexpectedly. (2) The granularity of events that can be selected with WSAAsyncSelect() is much finer than with select(), and thus an implementation would either be suboptimal, or not portable to other platforms. E.g., I had to add FD_ACCEPT and FD_CONNECT to the selected bit field for read events, and I assume that FD_CLOSE would have to be added also, to be compatible with select(), because this would also trigger on a close event, if the socket would be selected for read readiness. (3) To be implemented correctly, WSAAsyncSelect() would need a windows context. As implemented now, fl_window is used internally. If I understand the usage of fl_window correctly, then this is the current/last window that has been used or drawn. This behavior is _undefined_ from a programmer's view: I don't know, what would happen, if add_fd() would be called after showing/drawing a dialog window that would be destroyed later. Since Windows uses the window context (fl_window / HWND) to map to the message queue to deliver the messages to, it seems unclear, if the association of a socket to a windows message queue will be deleted, if this window would be destroyed. To be more explicit: if I understand the FLTK internals correctly, there is only one message queue associated with all FLTK windows. Thus, if windows would only use the HWND argument to associate the socket with the message queue, then it might be okay - but if it would associate the socket event handling with the window, then it might be disassociated when the window is destroyed. [Does anybody understand, what I mean here ? ;-) ] Conclusion: if there should be a way to implement it correctly, then IMHO the Fl::add_fd() API would have to be extended with a Fl_Window argument (a new, overloaded method). This argument would be ignored on all other platforms, and also on Windows, if USE_ASYNC_SELECT is not defined. My suggestion would be to document the problems shown here in the sources (and maybe also as an experimental option for users in doxygen comments, maybe under \todo), but leave USE_ASYNC_SELECT commented out. Some code changes should also be done to reflect the findings that I made so far. I'd volunteer to do so, if this would be decided. Any more comments on this? --- [1] http://msdn.microsoft.com/en-us/library/ms741540.aspx [2] http://msdn.microsoft.com/en-us/library/ms740141.aspx Link: http://www.fltk.org/str.php?L2029 Version: 1.3-current _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
