Carlo Wood wrote:
However, I think we should delay discussions of THIS type of details (related to point 2 above) a little longer. That does not mean I want to try and ignore your design, not at all! I like it and if its up to me we will use it exactly as you proposed...
I think it is a flaw to start with select() and wrap it, as I mentioned. Yes I consider ACE big and clunky, and I think it is clunky for this reason. I omitted detailed description of the 'core multiplexor' concept because it doesn't matter. It is trivial to implement for this interface, or most other reasonable interfaces. In my opinion, this is not a detail. This is the essence of the implementation. The value of a demultiplexor library for Boost will be measured in the efficacy and flexability of its interface, not based on whether it has builtin support for kqueue, for eg. Since you've been bringing it up, I feel quite strongly that the core demultiplexor should be based on MsgWaitForMultipleEventsEx in the usual case (when availible). I took Matthew Hurd's comments to heart, and I think another core policy should be based on polling. And another one for IOCP, certainly. For UNIX variants, a similar situation precides, with select() probably being the default, despite its flaws. (New POSIX AIO is another possibility--the Boost community seems to be suspiciously unconcerned with supporting nonstandard legacy UNIX variants.) (I am very interested on whether it is possible to meaningfully separate style of core--polling, select-esque--from the actual OS APIs--UNIX, Win32. So far, I think not, but I would like to.) Carlo Wood wrote:
One of the problems that can't seem to put a finger on is the fact that windows uses different types for file handles and for sockets.
How can I related HANDLE and SOCKET? And are there any other handle types that I am not aware of? Can SOCKET be casted to a HANDLE just like that? Or even converted without cast?
Well, this is pretty much a trivial implementation detail. I would like to express my frustration for the silliness of the situation involving Win32 names, as in practice they tend to work against encapsulation, not for it. Boost.Thread avoids all of the silliness of all of this by simply using void * as storage for handles, which as far as I know will work on any version of Windows in use or forseeable in the future. In my initial implementation