Re: [boost] Aaron's Informal Proposal for a Universal Demultiplexor for Boost

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-14 15:56:17

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