Re: Non-blocking I/O

From: williamkempf_at_[hidden]
Date: 2001-03-06 10:01:22

--- In boost_at_y..., pinkfloydhomer_at_y... wrote:
> --- In boost_at_y..., jeff_at_c... wrote:
> > > I would like to help myself, but I'm not sure I am the best 
person 
> > to 
> > > design or implement such a library. If no one else will work on 
> > this, 
> > > I will have to do it myself, but then I probably will not be 
able 
> > to 
> > > make a good enough design that it deserved to be in boost. I 
would 
> > > probably just make it work for my particular application, and 
no 
> > one 
> > > will ever benefit from it.
> > 
> > It seems to me that your core point about the standard library 
not 
> > addressing async programming issues is absolutely correct.  The 
> > interface you are postulating would most certainly be beneficial 
to 
> > the proposed boost Socket library.  Socket programming is another 
> > place where non-blocking control flow is needed for single 
threaded 
> > applications.  Which brings me to a question: why not put the 
input 
> > check in it's own thread?  
> > 
> 
> I have been thinking about doing this from the start. But I run into
> the same problem: threading is not portable.
> But I may end up doing it after all. It is IMO the most beautiful
> solution.

There are numerous thread libraries which are portable to at least a 
dominant group of platforms (i.e. Win32 and *nix type environments).

> > If you are even thinking about exploring this, I suggest you take 
a 
> > look at the ACE library
> (http://www.cs.wustl.edu/~schmidt/ACE.html).  
> > While it is overkill for what you are doing, this library has 
> > portable async I/O support classes.
> 
> Looks very nice and very usable for a huge number of problems,
> including mine. I was, however, thinking of using pthreads. I have
> found a very nice win32 pthread library, so now pthreads are 
available
> on all the platforms on which I would want my program to work.

Either approach would work, though ACE is probably better, since it's 
C++ based.  There are definate problems with using C based thread 
libraries in C++ that must be addressed by wrapping everything up 
into appropriate objects and documenting known issues (for example, 
terminating threads via "exit_thread" type calls or 
through "cancellations" will usually not unwind the stack properly, 
so destructors are not called and memory leaks or worse ensue).  ACE 
and other C++ wrappers try to address these problems for you so you 
don't get bogged down in the ugly details yourself.
 
> This brings me to another topic altogether:
> I can't see why C++ wouldn't have standard support for threading,
> networking, simple graphics etc. I know it's not very portable in
> terms of embedded systems, but so aren't a lot of standardized 
things.

It's worse then just embedded systems.  DOS, for one simple example, 
has no support for threads.  With out OS and/or hardware support 
you'd have to emulate thread support entirely in the language, which 
would be very difficult and would restrict you to a smaller subset of 
functionality (process shared synchronization objects, etc, would not 
work).  Unless the standard were to include "optional" libraries then 
the committee made the right choice, IMHO.  In the future, 
such "optional" libraries may be considered, and some committee 
members have voiced great interest in libraries such as this.

Boost is currently working on a portable threading library.  In fact, 
I'm one of the members working hard on it at this very moment.  With 
luck I'll have a rough draft of what will eventually be submitted 
posted here within a week or two of today.  It may take quite a while 
after this before it's actually submitted and accepted, because this 
particular library needs to be very carefully reviewed and designed, 
but you should see something accepted into Boost this year if I have 
anything to do with it.  In the mean time, the Files section has a 
Win32 implementation of some old work in progress on the library to 
give you some idea of what to expect.

Bill Kempf