DCEthreads - cancellation / mutexes is possible

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

hiya,

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.

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?

luke

p.s. the little 'stores' above - explanation: the demo is
to create an in-memory 'store', and to be able to do
file-like i/o (read, write, seek) on it.  it's actually
a static array of memory blocks, so they have to do mutex
around it.

Re: DCEthreads - cancellation / mutexes is possible

[dean gaudet <de...@arctic.org>]

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

[Justin Erenkrantz <je...@ebuilt.com>]

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

Re: DCEthreads - cancellation / mutexes is possible

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

On Tue, Jul 17, 2001 at 04:05:20PM -0700, dean gaudet wrote:
> 
> 
> 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.  

hiya dean,

i mentioned earlier that people might like to go over that codebase
[not with a fine-tooth-comb!] to review the techniques used, there,
rather than to actually use the code.

e.g. they have TRY / THROW / EXCEPT / CATCH macros that are
used _really_ extensively throughout the code, and i suspect
that these are a possible reason why MSVC++ adopted these macros
quite so early on [ms reimplemented a wire-compatible and
almost-api-compatible DCE/RPC]


> there's a thread FAQ somewhere which talks about async notification.

ack!

Re: DCEthreads - cancellation / mutexes is possible

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

On Tue, Jul 17, 2001 at 06:49:20AM -0700, rbb@covalent.net 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

[dean gaudet <de...@arctic.org>]

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

[rb...@covalent.net]

> 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.  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.

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------