Is Boost Threads missing "pthread_cancel"-like Functionality?
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.
Offlein escribió:
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...
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)
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.
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.
Raúl Huertas wrote:
I am not sure if Boost.Threads is actively maintained,
Yes it is.
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
Hi Roland, Roland Schwarz <roland.schwarz@chello.at> writes:
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.
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 -- Boris Kolpackov Code Synthesis Tools CC http://www.codesynthesis.com Open-Source, Cross-Platform C++ XML Data Binding
Hi Roland,
Roland Schwarz <roland.schwarz@chello.at> writes:
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
Boris Kolpackov escribió: parts of the code can be cancellated and how to react to this cancellation.
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...
Boris Kolpackov wrote:
Roland Schwarz <roland.schwarz@chello.at> writes:
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
participants (2)
-
Boris Kolpackov -
Offlein -
Raúl Huertas -
Roland Schwarz