...

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? Emil Dotchevski _________________________________________________________________ It’s tax season, make sure to follow these few simple tips http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.a...