[cpp-threads] Asynchronous Execution Issues (caching_async)

[Boehm, Hans]

I think we're also clear on the fact that the suggested solutions are fairly drastic.  But I think the problems described in the paper are serious.  If we had reasonable alternatives, I'd prefer not to be suggest changes like this, especially at this stage.

Hans

> -----Original Message-----
> From: Lawrence Crowl [mailto:lawrence.crowl at gmail.com] 
> Sent: Friday, May 01, 2009 3:34 PM
> To: C++ threads standardisation
> Cc: Boehm, Hans; Bjarne Stroustrup
> Subject: Re: [cpp-threads] Asynchronous Execution Issues 
> (caching_async)
> 
> On 5/1/09, Anthony Williams 
> <anthony at justsoftwaresolutions.co.uk> wrote:
> > At Fri 01 May 2009 22:34:17 BST, "Boehm, Hans" 
> <hans.boehm at hp.com> wrote:
> > > Here's a draft of a paper on these issues that Lawrence and I are 
> > > about to submit.
> >
> > Sorry for my lack of reply earlier. I didn't see the messages until 
> > now.
> >
> > I'm concerned about removing detach(). It makes it very 
> hard (if not 
> > impossible) to write a simple async function without using a thread 
> > pool unless one also has a wait-for-the-thread variant of a future. 
> > Even with a wait-for-the-thread future, what happens if 
> no-one waits? 
> > Do we get a thread leak? Join on destruction? Throw on destruction?
> 
> I would join on destruction, because I expect the destruction 
> to happen without the wait mostly when the wait is bypassed 
> by an exception, and I'd rather not put an exception in a destructor.
> 
> > Also, people will expect detach().  Boost has it.  POSIX has it.
> > Both have destructors for thread-locals.  This would be 
> seen as a big 
> > step backwards.
> 
> We need to ensure that C++0x can solve the problems for which 
> others used detach.  A careful analysis of examples might 
> yield some interesting insights.
> 
> --
> Lawrence Crowl
>