Is Boost Threads missing "pthread_cancel"-like Functionality?

[Offlein]

Hi all,

i'm missing something like PThread's pthread_cancel.
Is there a Way to use Boost::Threads in a similar Way.
I looked in the Docu and didn't find anything similar to pthread_cancel.

Is there another Functionality which kind of "implement" this Behaviour of PThreads or am i blind and don't see where it's written in the Docu?
I don't want to use anything else because Boost is a very good Collection of Libraries, which are very well written.

[Raúl Huertas]

Post by Offlein
Hi all,
i'm missing something like PThread's pthread_cancel.

In point 9 of
http://tinyurl.com/yn2y7m
it is stated:
"There's a valid need for thread termination, so at some point
Boost.Threads probably will include it, but only after we can find a
truly safe (and portable) mechanism for this concept."

I am not sure if Boost.Threads is actively maintained, so I don't know
when "at some point" is...

Post by Offlein
Is there a Way to use Boost::Threads in a similar Way.
I looked in the Docu and didn't find anything similar to pthread_cancel.

We normally use some kind of inter-thread communication for that purpose.
If we communicate threads using a message queue, for example, we have a
message that says: "ok, time to die". ;)
It is not the same, but it is almost always sufficient (In our work, we
use a lot of sockets, so we have developed similar mechanisms that we
use for socket.read's or ::select's, for example)

Post by Offlein
Is there another Functionality which kind of "implement" this Behaviour of PThreads or am i blind and don't see where it's written in the Docu?

I don't think so.

Post by Offlein
I don't want to use anything else because Boost is a very good Collection of Libraries, which are very well written.

Yes, I agree. :-)

Regards.

[Roland Schwarz]

Post by Raúl Huertas
I am not sure if Boost.Threads is actively maintained,

Yes it is.

Post by Raúl Huertas
so I don't know
when "at some point" is...

Altough I should know (I am one of the maintainers), honestly I don't.
The issue is notoriously hard to get at (especially on windows).
The issue is however actively discussed by the C++ standards group.

The main questions are about proper interaction with exceptions.

If you carefully rethink the need for cancellation you most likely will
find that you really will need cancellation rarely. You almost always
can use some other interthread communication mechanisms.

You also might take a look on my thread alerter which I have posted to
the vault quite some time ago. This is written on top of Boost.Thread
but does not implement cancellation. However you will be able to "wake
up" a thread that is in some form of "waiting". Often this is what you
really need. Full blown cancellation often is a too coarse grained tool
anyways.

Roland

[Boris Kolpackov]

Hi Roland,

Post by Roland Schwarz
If you carefully rethink the need for cancellation you most likely will
find that you really will need cancellation rarely. You almost always
can use some other interthread communication mechanisms.

It also almost always requires sneaking an ugly "special case" into
an otherwise clean and simple code (e.g., a special cancellation pipe
for a thread waiting on select, a special flag for a thread waiting on
condvar, etc.). It is in essence very similar to the exceptions vs
error codes debate; as with exceptions, with proper thread cancellation
you can separate the main logic from the thread termination code.

Post by Roland Schwarz
Full blown cancellation often is a too coarse grained tool anyways.

I find this statement unsubstantiated. Can you elaborate a bit on this?


thanks,
-boris

[Raúl Huertas]

Post by Boris Kolpackov
Hi Roland,

Post by Roland Schwarz
If you carefully rethink the need for cancellation you most likely will
find that you really will need cancellation rarely. You almost always
can use some other interthread communication mechanisms.

It also almost always requires sneaking an ugly "special case" into
an otherwise clean and simple code (e.g., a special cancellation pipe
for a thread waiting on select, a special flag for a thread waiting on
condvar, etc.).

Yes, it is ugly ;), but thread cancellation is not a special case, IMHO.
In my point of view, it has to be part of all the code that the thread
uses. For me, it is important that the programmer thinks about what
parts of the code can be cancellated and how to react to this cancellation.

Post by Boris Kolpackov
It is in essence very similar to the exceptions vs
error codes debate; as with exceptions, with proper thread cancellation
you can separate the main logic from the thread termination code.

Yes, it is similar in essence, but I reserve exceptions for the
exceptional cases ;), and I'm not sure that thread cancellation can be
an exceptional case. For example, I use exceptions when my programs runs
out of file descriptors, but I do not use them when I can't open a file.
I suppose that, in the end, it is a matter of tastes, but I don't like
that the programmers don't think about thread cancellation because an
automated mechanism (similar to exceptions) dos the job for them. I only
let the programmers not to think when the job is very easy... ;)


Just my two cents...

Raul.
P.S.: Forgive my English, I'm trying hard to learn it...

[Roland Schwarz]

Post by Boris Kolpackov

Post by Roland Schwarz
Full blown cancellation often is a too coarse grained tool anyways.

I find this statement unsubstantiated. Can you elaborate a bit on this?

Full cancellation has to preserve invariants. I.e. you don't want to
leave any system or heap objects, behind. So cancellation has to clean
up properly. So it inevitably has to interact intimately with stack
unwinding, and exceptions.
Also cancellation is an all or nothing decision.

I often find my thread hanging in an input or waiting for some condition
which I simply want it to stop. Yes I regard this as an exceptional
thing, which I would like to be able to throw at the thread.

So when you can "alert" a thread which in turn ends waiting by means of
an exception, I can caught this in my code and do whatever is
appropriate. This might even be to attempt another input possibly by
acquiring a different resource, without even ending the thread.

Yes and I would like to be able to do this without explicit reference to
a global state from each and every call to wait, io, ...

For an example of how this could be done, see my alerter. (As far as I
remember the prototype is using broadcasts, since I tried to build it on
top of Boost.Thread. But I think this could be optimized.)

Hope this explains what I meant by "coarse grained".

Roland