Re: [boost] Re: Boost.Threads - thread_desc concept

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-28 17:13:41

From: John Max Skaller <skaller_at_[hidden]>
> williamkempf_at_[hidden] wrote:
> > 
> > --- In boost_at_y..., John Max Skaller <skaller_at_o...> wrote:
> > > Greg Colvin wrote:
> > >
> > > > Because killing threads is a bad idea.
> > >
> > >       No, it isn't a 'bad idea'. It is essential
> > > in many applications, in particular, it is essential
> > > in most multithreaded servers to kill client connection
> > > management threads when they're unable to detect that
> > > the connection is lost or exceeded some bound
> > > (such as 'out of money').
> 
> []
> 
> >  Considering all of this, I think 'bad idea' is a proper
> > description.
> 
> What you seem to have been saying is that
> it would be a bad idea to include cancellation in
> the library being designed. I have no argument with that
> at all. My argument is with the blanket assertion
> that cancellation is a 'bad idea'.

Thre is some confusion here because I have taken cancellation
to mean stopping a thread with no stack unwinding, an operation
that has been deprecated in java because of the trouble it was
causing.  The replacement is called interruption, which causes
an exception to be thrown on the thread, unblocking if needed.
No doubt there are other possibilities.

I don't know what is the best design for C++, but I agree with
you that it is a core issue, and not one that I think we want
to commit to in the first release of this library.

> It obviously isn't: if a thread is blocked,
> there is NO alternative: by specification,
> the thread is to be killed from outside without
> possibility of its cooperation. 
> 
> One way around this would be to provide non-blocking
> operations and use polling. Another would be to provide
> cancellable operations: function that return when they succeed,
> or when the thread is cancelled -- which requires testing
> every such functions return code for cancellation.
> 
> There are lots of alternative designs,
> but if you are going to use a particular API like
> Posix you may HAVE to use cancellation BECAUSE
> of the design of the API.
> 
> Please think carefully about this.
> Blocking operations exist: many socket operations
> block. What do you do if a thread is blocking
> on a socket operation, and another thread discovers
> that the connection should be disallowed?
> 
> You could set a flag and assume that
> the operation will time out, AND that the thread
> in question will actually test the flag.
> Or you can cancel it, releasing some valuable
> resources with more certainty; and also
> ensuring that the client on the other end of the
> socket cannot gain unauthorized access, perhaps
> due to a bug in the thread.
> 
> I don't think it can be decided that
> cancellation is wrong as a matter of principle,
> when business/security/resource requirements
> may dictate a higher priorty for such matters
> than the integrity of the thread itself.
> There's a matter of judgement here, and the
> weighting factors are not all C++ technical
> design issues.
> 
> Perhaps, in an advanced design such
> as the join calculus, cancellation isn't meaningful.
> But with Posix, it is: its part of the API for a
> reason: to meet real needs.
> 
> -- 
> John (Max) Skaller, mailto:skaller_at_[hidden] 
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> New generation programming language Felix  http://felix.sourceforge.net
> Literate Programming tool Interscript     
> http://Interscript.sourceforge.net
> 
> Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
>