Its not a great idea to know some of your threads
might not return for whatever reason - DCOm calls
WILL return whatever be the error created if not
you might have chanced upon a new found bug and
it will be great to share it here

If its for some other reason other than DCOM like
programmatic errors ,you could use standard solutions
like exception handling etc - basically guarantee that
your threads always return -

Its much bettr that way than designing around what might
be a basic problem in the outset

arun

----- Original Message -----
From: "Charles Gamble" <Charles.GambleSINGULARITY.CO.UK>
To: <DCOMDISCUSS.MICROSOFT.COM>
Sent: Wednesday, February 13, 2002 8:49 PM
Subject: Re: RPC Call failed after killing thread

> Hi Joe,
>
> Thanks for the help. We feel that we need to call TerminateThread as we
have
> a product that calls 3rd party COM methods over which we have no control,
> they may run on local or remote machine and may never return . For
> misbehaving ones i.e ones that don't return for whatever reason we need
the
> ability to be able to "kill" the calling thread in our exe as it is of no
> use.
> The only way we know that was can do this is terminatethread and then
> allocate a new one in our exe.
>
> If there are other ways to achieve this then we would be very gratefull,
we
> need a solution that works under nt4.0.
>
> Is is really a solution to leave these threads lying around and taking up
> memory space etc. ?
>
> Charles.
>
>
> -----Original Message-----
> From: Joe O'Leary [mailto:jmolearyEARTHLINK.NET]
> Sent: 13 February 2002 14:23
> To: DCOMDISCUSS.MICROSOFT.COM
> Subject: Re: RPC Call failed after killing thread
>
>
> Hi Charles,
>
> You say
>
> "Sometimes I need to kill threads
> in the EXE which are in-call to an MTS
> component.
>
> by which I assume you mean calling TerminateThread(), right?
>
> In response I would say stop right there. You should never -- and I mean
> NEVER need to kill threads. TerminateThread is probably the single most
> evil Win32 API function there is. It simply stops the thread without
> releasing any of its resources. If, for example, the thread you terminate
> has a mutex locked, that mutex stays locked until your process goes away.
> Ouch.
>
> It's no wonder that your calls start failing after killing the thread.
> Frankly, I'm surprised that anything works at all. You have GOT to find a
> better way than TerminateThread, believe me.
>
> Now granted, the TerminateThread function is there for a reason. I'm sure
> there are some scenarios where using it is valid, but personally, I think
> you should avoid it all costs. Open up just about any book on Win32
> multithreaded programming (e.g. Jeff Richter's stuff) and you'll find the
> same advice.
>
> I've been doing multi-threaded Windows programming since Win32 first
became
> a reality (Windows NT 3.1, I think). I've been in middleware most of that
> time, working on radar systems, ID systems, and database servers, and
> PC-based PBX switching software. Most of these jobs involved complicated
> threading scenarios.
>
> In all that time, I have yet to encounter a situation where
TerminateThread
> was truly needed. Oh I've seen people use it occasionally, but never
where
> I thought it was warranted. At least once, I have gone in and removed
> TerminateThread calls inserted by someone else. The thing is, once you
kill
> a thread, you really can't trust that anything in your process is going to
> work properly anymore.
>
> Try redesigning your application so that you do not need to kill threads.
> Perhaps Asynchronous DCOM might be your ticket. Or, if necessary, you
could
> insert some sort of manual call-dispatching mechanism with a manual timer
to
> make the calls. It's actually not all that difficult (I've done it a
couple
> of times myself).
>
> In other words, instead of the simple normal situation
>
> Thread A makes the DCOM call and blocks for
> too long (or forever)
>
> You could have this:
>
> Thread A passes the arguments to Thread B
> which makes the DCOM call. Thread A waits
> for Thread B to signal that the call has
> returned. If Thread B takes too long in
> the call, Thread A times out and assumes it
> failed.
>
> In effect, thread B is effectively abandoned in this scenario. Far better
> to abandon a thread than to terminate it.
>
> Sorry to be so long winded, but Arun is right. Signaling a thread to end
> is the proper and safe way.
>
> Hope this helps,
>
> Joe
>
> -----Original Message-----
> From: ArunKumar <akumarOMNESYSINDIA.COM>
> Date: Wed, 13 Feb 2002 19:28:46 +0530
> To: DCOMDISCUSS.MICROSOFT.COM
> Subject: Re: RPC Call failed after killing thread
>
>
> > jeez i have same kinda setup but using messages to signal threads
> > to exit of their own -
> >
> > what kindof apartments do u use ?
> >
> > ----- Original Message -----
> > From: "Charles Gamble" <Charles.GambleSINGULARITY.CO.UK>
> > To: <DCOMDISCUSS.MICROSOFT.COM>
> > Sent: Monday, February 11, 2002 4:40 PM
> > Subject: FW: RPC Call failed after killing thread
> >
> >
> > > Anyone have any ideas on this one?
> > >
> > > Steve Swartz?
> > >
> > > Thanks for the help,
> > > Charles.
> > >
> > >
> > > -----Original Message-----
> > > From: Charles Gamble [mailto:Charles.GambleSINGULARITY.CO.UK]
> > > Sent: 24 January 2002 15:11
> > > To: DCOMDISCUSS.MICROSOFT.COM
> > > Subject: RPC Call failed after killing thread
> > >
> > >
> > > Hi all,
> > >
> > > I have an EXE which is used to create threads which talk to MTS
> > components.
> > > My problem is this:
> > > Sometimes I need to kill threads in the EXE which are in-call to an
MTS
> > > component. (I only use one package, so there is only one MTX.EXE)
> > > When the thread in MTX.EXE which was in-call then dies later on and
> tries
> > to
> > > return to my EXE, the first call I then try to make to an MTS
component
> > from
> > > a new thread in my EXE fails with the error 800706be: The remote
> > procedure
> > > call failed.
> > >
> > > If I just try to make the call again, it works fine.
> > > Why does this happen for the first call into the MTX.EXE from my EXE?
> > > Note it only happens after the thread which was previously in call in
> MTS
> > > tries to return to the killed thread in my EXE.
> > > I have tried calling MTS from another process but this problem only
> occurs
> > > in the EXE which I had previously killed the in-call thread.
> > >
> > > Thanks for this.
> > > Charles.
> > >
> > > ----------------------------------------------------------------
> > > Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> > > contains important info. Save time, search the archives at
> > > http://discuss.microsoft.com/archives/index.html .
> > > To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
> > >
> > > ----------------------------------------------------------------
> > > Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> > > contains important info. Save time, search the archives at
> > > http://discuss.microsoft.com/archives/index.html .
> > > To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
> >
> > ----------------------------------------------------------------
> > Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> > contains important info. Save time, search the archives at
> > http://discuss.microsoft.com/archives/index.html .
> > To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
> >
>
> --
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]