Re: [boost] Next revision of boost::thread

From: Stefano Delli Ponti (stefano.delliponti_at_[hidden])
Date: 2003-01-09 13:43:26

----- Original Message -----
From: "William E. Kempf" <wekempf_at_[hidden]>
> > From: "Stefano Delli Ponti" <stefano.delliponti_at_[hidden]>
> > From: "William E. Kempf" <wekempf_at_[hidden]>
> > > > From: "Stefano Delli Ponti" <stefano.delliponti_at_[hidden]>
> > > > From: "David Abrahams" <dave_at_[hidden]>
> > > > > "William E. Kempf" <wekempf_at_[hidden]> writes:
> > > > >
> > > > > > That's a good idea.  So would users prefer new exception types
here,
> > > > > > or should I use the std:: exceptions?
> > > > >
> > > > > IMO, it's always safer to use an exception type which provides
> > > > > more-specific information.
> > > >
> > > > Agreed. And we should keep coherence with the filesystem library.
> > >
> > > I'm not sure there's any coherence to keep here.  Do you have specific
> > concerns/thoughts here?
> >
> > I was thinking about keeping similar design patterns between these two
> > libraries.
> > (because they are conceptually similar as they both give a portable view
of
> > operating system functionalities).
> > So if we use domain specific exception in the filesystem library, the
thread
> > library should follow the same pattern too. The same for the issue of
> > conditional compilation.
>
> I'll look at this closer, but the domains are different enough that I'm
not sure there's anything that carries over.
>
> As for conditional compilation... the Boost.Filesystem stuff has no need
for this, while Boost.Threads has a very definate need.

Probably it has no need for this now, but I think it will have the same need
in the future.

> > BTW I prefer having the same set of methods, some of them returning
default
> > values for platform without the support for the underline concept.
> > Sometimes this could not be possible. ACE for instance uses a different
> > approach.
>
> Again, dummy stubs won't work in all cases.  A better example than I've
already given is the attribute to make a mutex visible across process
boundaries.  Not all platforms will support this, and if they don't a stub
that returns an error or throws an exception is doing a great disservice to
the developer, since he should know at compile time that this platform can't
handle this, since there's nothing he can do at run time to compensate for
the lack.

Of course.
I was thinking more about set/get methods for properties/attributes  here
like
    attributes& stack_size(size_t size);
    size_t stack_size() const;

Dummy stubs (even if often unclear) help to reduce the need for conditional
compilation to the library's user.

I would dare to suggest that the "basic" thread class, if the thread concept
is supported, had _all_ of its methods available and implemented (or dummy)
for _all_ the platforms (!).
I would be inclined to have an "advanced" attribute like the one to make a
mutex visible across process boundaries available only on an "advanced"
class like process_mutex. The "basic" mutex, if the concept is supported,
could have the same signatures for all the platforms.

Sted