From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-25 16:38:09
> > If all of your code is in C++, you'd know not to call pthead_cancel because> > it won't work. That would be no problem because you can work at the C++> > <thread> level where everything is nice and cool -- but what if a 3rd party> > library built on <pthread> calls pthread_cancel?> > Then it would be a very bad library. A library should either create its > own threads and then it is the responsible to join/detach/cancel it, or > it works with thread created by the application and then shouldn't do > any of those things. Just as Howard's example with > malloc/free/new/delete - what happens if I pass a pointer created with > new to a library which tries to deallocate it using free? Bad things > happen. I shouldn't do it, and more than that, such a library, that > tries to free a pointer not allocated by it, is not a good friend of mine.
The malloc/free/new/delete reference is not appropriate: I wasn't saying that someone would pthread_cancel a thread created using the C++ <thread> interface. The C library creates threads, the C library cancels them; the question is, what happens when the C library cancels a thread it created, which happens to be running C++ code at the time?
Its tax season, make sure to follow these few simple tips
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk