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

Reply via email to