Re: DCEthreads - cancellation / mutexes is possible
On Tue, 17 Jul 2001, Luke Kenneth Casson Leighton wrote: therefore, i conclude that the dce/rpc codebase has successfully implemented thread cancellation in their POSIX/Draft4 thread library. yes cancellation is in the spec. i've never denied that. the problem is libraries and code over which we have no control. there's a thread FAQ somewhere which talks about async notification. -dean
Re: DCEthreads - cancellation / mutexes is possible
On Tue, 17 Jul 2001, Justin Erenkrantz wrote: 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 cancellation is a subset of notification :) -dean
Re: DCEthreads - cancellation / mutexes is possible
On Tue, Jul 17, 2001 at 06:49:20AM -0700, [EMAIL PROTECTED] wrote: well, in amongst all this about threads etc. i just wanted to let you know that i happened across the context_app example in the dce 1.22 codebase. it is an example client and server that maintains a context - a persistent connection across multiple remote function calls. this implies that if the connection dies without the client destroying the context, then the server must do it _for_ you [by calling context_name_t_rundown which you *have* to provide: it calls it on every outstanding context of type 'context_name_t' it is an auto-generated function.] and that means killing a thread. and _that_ implies thread cancellation and cleanups. and it works. therefore, i conclude that the dce/rpc codebase has successfully implemented thread cancellation in their POSIX/Draft4 thread library. That is quite a leap in logic there. okay, so i'm a rutherford instead of an einstein [rutherford was known for knowing what the answer was, and then cooking the books to get the missing steps between the question and the correct answer :) :) iow, i know that dce threads have cancellation. like sander says, this is pretty hard-core code used in things like the National Insurance Database, military and government-mandated applications etc., so... I can think of multiple ways that the thread itself could timeout and kill itself. You also haven't mentioned how much memory was leaked by killing that thread. I am not saying you are wrong, just that with the information you provided above, I am not convinced that they have actually successfully implemented async killing of threads. okay. i tried a little test. just before freeing the context, i instead call exit(0). i presume that this is a Bad Thing To Do? there is even a client thread so i presume doing this sort of thing is Not Good. then i do this: while 1; do ./context_client 'test message'; done; now, this generates about... difficult to tell, the screen scrolls so quickly... 50 clients per second, at a guess? i left it for about a minute, and then examined the server apps [there are 10 threads forked off]. the memory usage did NOT change / go up. ... just tried it again [2 mins]: *giggle*. oh dearie me: The Open Group is going to be so pissed :) memory usage went up from 1584 to 1608 and now the server isn't accepting connections any more. teehee :) [... ah, no: it's recovered again. hey, this is just plain odd. okay, could just be i'm overloading my computer :) ] yep: been running on-and-off for several minutes: ps auxw shows no obvious memory leaks. if you know a better way than ps axuw please let me know! luke
Re: DCEthreads - cancellation / mutexes is possible
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
