[boost] Re: What I Hate About How We Abstract System Dependence

From: Boris (boris_at_[hidden])
Date: 2005-03-07 12:52:07

Aaron W. LaFramboise wrote:
> [...]
> So here’s my question to the Boost community.  How many people have
> similar concerns and experiences?  How often, in real code, do

We face similar questions in the design of the socket library. There are 
basically two I/O models: synchronous and asynchronous read-/write-methods. 
The asynchronous I/O model can be implemented quite differently using 
multiplexing, aio, I/O completion ports, threads etc. Now someone said he 
wants to have some sort of control about how the asynchronous I/O model 
works eg. by specifying the number of background threads. Clearly that would 
be only possible if the asynchronous I/O model is based on threads. 
Currently I assume there are just two classes synchronous and asynchronous 
but I can think of lots of other classes that might be added later and 
inherit from asynchronous.

Your posting reminds me a bit of the compliance levels in UML 2.0. 
Everything in UML 2.0 belongs either to Basic (level 1), Intermediate (level 
2) or Complete (level 3). In order to compare capabilities of UML tools 
there is either no compliance, partial compliance, compliant compliance or 
interchange compliance. It's more complicated than a simple black and white 
but a tribute to the fact that black and white just doesn't exist in 
reality. I don't know about Boost.Thread but I understand that some library 
users would like to know how an asynchronous I/O model works and what they 
can do about it.

Boris