On Tue, Jul 17, 2001 at 03:26:29PM +0200, Luke Kenneth Casson Leighton wrote: > therefore, i conclude that the dce/rpc codebase has successfully > implemented thread cancellation in their POSIX/Draft4 thread > library. > > additionally, the context app, being threaded, has to have > locking on the little 'stores' it maintains. i do not know > what it means [well, okay, i do, but i've never actually > programmed with threads is more like it] but there is some > code in there that mentions 'mutex'. > > i presume that this is working, too. > > does this help answer your question, justin?
I don't like cancellation of threads from a design perspective. I don't care much that some test "works." It wasn't an issue of whether the underlying OS supports cancellation of threads - it was an issue that this now becomes a nightmare to code up correctly. We now need to add cancellation points, and there are certain activities that the thread may enter which are non-cancellable no matter what we do (i.e. mutex acquisition). AIUI, the dce/rpc codebase is a commercial *user-space* threading add-on. Yuck. -1 on dce/rpc for that aspect alone. -1 on having cancellation of threads based on the overall design. I abhor the idea of a thread being forced to exit against its wishes. It will just lead us down a road that I don't wish to go down in APR. Now, if someone wants to write a httpd MPM that uses cancellation, be my guest. I can't stop you (I don't have commit access there and hence veto power). In fact, before even considering cancellation support in APR, I'd want to see a MPM that uses cancellation properly and is just as robust (hehe) as the current threading MPM. When that occurs, I might be willing to reconsider. And, from what I can tell, Dean Gaudet has mentioned this morning that he is willing to veto async notification. Dean, would that include cancellation of threads? I have a suspicion it might. Dean has commit access on httpd as well, so if you can convince Dean to change his mind, I'll change mine. -- justin
