Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-28 17:02:31

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'.

        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
Literate Programming tool Interscript

Boost list run by bdawes at, gregod at, cpdaniel at, john at