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