hi all,
Is there any way to gracefully terminate (other than using TerminateThread) a blocked thread in Nt/2000/2003?
regards
Deepu.L.R
No. The thread is blocked for a reason, and, if the reason did not occur, then it must stay waiting.
Note that TerminateThread is a bad API (it causes the user stack of the thread to go leak), practically never useful. Why ever terminating a thread inside the alive process which continue to run?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Deepu.L.R
To: Windows System Software Devs Interest List
Sent: Thursday, January 29, 2004 1:47 PM
Subject: [ntdev] Gracefully killing a blocked thread
hi all,
Is there any way to gracefully terminate (other than using TerminateThread) a blocked thread in Nt/2000/2003?
regards
Deepu.L.R
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
So, if the reason for the blocking has crashed and we know that the thread
is never going to be unblocked, should it stay there forever like a zombie ?
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Thursday, January 29, 2004 11:09 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Gracefully killing a blocked thread
No. The thread is blocked for a reason, and, if the reason did not
occur, then it must stay waiting.
Note that TerminateThread is a bad API (it causes the user stack of the
thread to go leak), practically never useful. Why ever terminating a thread
inside the alive process which continue to run?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com mailto:xxxxx
http://www.storagecraft.com http:
----- Original Message -----
From: Deepu.L.R mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx List
Sent: Thursday, January 29, 2004 1:47 PM
Subject: [ntdev] Gracefully killing a blocked thread
hi all,
Is there any way to gracefully terminate (other than using
TerminateThread) a blocked thread in Nt/2000/2003?
regards
Deepu.L.R
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
mailto:xxxxx
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
Presumably you would have an “error” or “abort” synchronization object
that the thread is waiting on in addition to whatever other objects it’s
waiting on.
Chuck
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 29, 2004 11:18 PM
Subject: RE: [ntdev] Gracefully killing a blocked thread
> So, if the reason for the blocking has crashed and we know that the
thread
> is never going to be unblocked, should it stay there forever like a
zombie ?
>
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
Shatskih
> Sent: Thursday, January 29, 2004 11:09 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Gracefully killing a blocked thread
>
>
>
> No. The thread is blocked for a reason, and, if the reason did not
> occur, then it must stay waiting.
>
> Note that TerminateThread is a bad API (it causes the user stack
of the
> thread to go leak), practically never useful. Why ever terminating a
thread
> inside the alive process which continue to run?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com mailto:xxxxx
> http://www.storagecraft.com http:
>
>
> ----- Original Message -----
> From: Deepu.L.R mailto:xxxxx
> To: Windows System Software Devs Interest
mailto:xxxxx List
>
> Sent: Thursday, January 29, 2004 1:47 PM
> Subject: [ntdev] Gracefully killing a blocked thread
>
> hi all,
>
> Is there any way to gracefully terminate (other than using
> TerminateThread) a blocked thread in Nt/2000/2003?
>
> regards
> Deepu.L.R
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> http:
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> mailto:xxxxx
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the
named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
Yet that may not help if I get into a situation where there’s a potential
deadlock that I may want to rollback by killing one of the deadlocked
threads. That synchronization object may not be mine, yet my thread is hung
on it, now what ?
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
Sent: Thursday, January 29, 2004 11:39 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Gracefully killing a blocked thread
Presumably you would have an “error” or “abort” synchronization object
that the thread is waiting on in addition to whatever other objects it’s
waiting on.
Chuck
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 29, 2004 11:18 PM
Subject: RE: [ntdev] Gracefully killing a blocked thread
> So, if the reason for the blocking has crashed and we know that the
thread
> is never going to be unblocked, should it stay there forever like a
zombie ?
>
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
Shatskih
> Sent: Thursday, January 29, 2004 11:09 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Gracefully killing a blocked thread
>
>
>
> No. The thread is blocked for a reason, and, if the reason did not
> occur, then it must stay waiting.
>
> Note that TerminateThread is a bad API (it causes the user stack
of the
> thread to go leak), practically never useful. Why ever terminating a
thread
> inside the alive process which continue to run?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com mailto:xxxxx
> http://www.storagecraft.com http:
>
>
> ----- Original Message -----
> From: Deepu.L.R mailto:xxxxx
> To: Windows System Software Devs Interest
mailto:xxxxx List
>
> Sent: Thursday, January 29, 2004 1:47 PM
> Subject: [ntdev] Gracefully killing a blocked thread
>
> hi all,
>
> Is there any way to gracefully terminate (other than using
> TerminateThread) a blocked thread in Nt/2000/2003?
>
> regards
> Deepu.L.R
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> http:
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> mailto:xxxxx
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the
named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
with events there’s no ownership information, so using events for
anything other than signalling is a bad idea.
on the other hand, mutexes track ownership and a wait on one would
return STATUS_ABANDONED if the owner terminated.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moreira, Alberto
Sent: Thursday, January 29, 2004 9:28 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Gracefully killing a blocked thread
Yet that may not help if I get into a situation where there’s a
potential deadlock that I may want to rollback by killing one of the
deadlocked threads. That synchronization object may not be mine, yet my
thread is hung on it, now what ?
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
Sent: Thursday, January 29, 2004 11:39 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Gracefully killing a blocked thread
Presumably you would have an “error” or “abort” synchronization object
that the thread is waiting on in addition to whatever other objects it’s
waiting on.
Chuck
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 29, 2004 11:18 PM
Subject: RE: [ntdev] Gracefully killing a blocked thread
> So, if the reason for the blocking has crashed and we know that the
thread
> is never going to be unblocked, should it stay there forever like a
zombie ?
>
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
Shatskih
> Sent: Thursday, January 29, 2004 11:09 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Gracefully killing a blocked thread
>
>
>
> No. The thread is blocked for a reason, and, if the reason did not
> occur, then it must stay waiting.
>
> Note that TerminateThread is a bad API (it causes the user stack
of the
> thread to go leak), practically never useful. Why ever terminating a
thread
> inside the alive process which continue to run?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com mailto:xxxxx
> http://www.storagecraft.com http:
>
>
> ----- Original Message -----
> From: Deepu.L.R mailto:xxxxx
> To: Windows System Software Devs Interest
mailto:xxxxx List
>
> Sent: Thursday, January 29, 2004 1:47 PM
> Subject: [ntdev] Gracefully killing a blocked thread
>
> hi all,
>
> Is there any way to gracefully terminate (other than using
> TerminateThread) a blocked thread in Nt/2000/2003?
>
> regards
> Deepu.L.R
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> http:
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> mailto:xxxxx
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the
named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only.
It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or
disclose
it to anyone else. If you received it in error please notify us
immediately
and then destroy it.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
You should have a sync. object that is yours, a unique one per thread
if necessary (i.e. if you want per-thread abortion control), that is
used to abort any and all waits in a thread. The point being that your
thread should never be able to hang indefinitely on any particular wait
(because you can exit any particular wait by signalling the appropriate
abort sync. object), and give the thread a chance to clean up before
terminating.
Chuck
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Friday, January 30, 2004 12:27 AM
Subject: RE: [ntdev] Gracefully killing a blocked thread
> Yet that may not help if I get into a situation where there’s a
potential
> deadlock that I may want to rollback by killing one of the deadlocked
> threads. That synchronization object may not be mine, yet my thread is
hung
> on it, now what ?
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> Sent: Thursday, January 29, 2004 11:39 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Gracefully killing a blocked thread
>
>
> Presumably you would have an “error” or “abort” synchronization object
> that the thread is waiting on in addition to whatever other objects
it’s
> waiting on.
>
> Chuck
>
> ----- Original Message -----
> From: “Moreira, Alberto”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, January 29, 2004 11:18 PM
> Subject: RE: [ntdev] Gracefully killing a blocked thread
>
>
> > So, if the reason for the blocking has crashed and we know that the
> thread
> > is never going to be unblocked, should it stay there forever like a
> zombie ?
> >
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
> Shatskih
> > Sent: Thursday, January 29, 2004 11:09 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Gracefully killing a blocked thread
> >
> >
> >
> > No. The thread is blocked for a reason, and, if the reason did
not
> > occur, then it must stay waiting.
> >
> > Note that TerminateThread is a bad API (it causes the user stack
> of the
> > thread to go leak), practically never useful. Why ever terminating a
> thread
> > inside the alive process which continue to run?
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com mailto:xxxxx
> > http://www.storagecraft.com http:
> >
> >
> > ----- Original Message -----
> > From: Deepu.L.R mailto:xxxxx
> > To: Windows System Software Devs Interest
> mailto:xxxxx List
> >
> > Sent: Thursday, January 29, 2004 1:47 PM
> > Subject: [ntdev] Gracefully killing a blocked thread
> >
> > hi all,
> >
> > Is there any way to gracefully terminate (other than using
> > TerminateThread) a blocked thread in Nt/2000/2003?
> >
> > regards
> > Deepu.L.R
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > http:
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > mailto:xxxxx
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee
only.
> It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the
named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
The “reason for the blocking” is inside the same process - or inside the kernel.
If it is inside the same process - then kill the process and restart it (together with the address space data). At least the new process will be guaranteed to be operable.
If it is inside the kernel - then sorry, but you need to reboot.
I can hardly imagine the multi-threaded architecture which will be able to recover from the situation when one of its threads was killed by TerminateThread.
That is why the unhandled exception kills the whole process and not the thread.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Moreira, Alberto
To: Windows System Software Devs Interest List
Sent: Thursday, January 29, 2004 7:18 PM
Subject: RE: [ntdev] Gracefully killing a blocked thread
So, if the reason for the blocking has crashed and we know that the thread is never going to be unblocked, should it stay there forever like a zombie ?
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Thursday, January 29, 2004 11:09 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Gracefully killing a blocked thread
No. The thread is blocked for a reason, and, if the reason did not occur, then it must stay waiting.
Note that TerminateThread is a bad API (it causes the user stack of the thread to go leak), practically never useful. Why ever terminating a thread inside the alive process which continue to run?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Deepu.L.R
To: Windows System Software Devs Interest List
Sent: Thursday, January 29, 2004 1:47 PM
Subject: [ntdev] Gracefully killing a blocked thread
hi all,
Is there any way to gracefully terminate (other than using TerminateThread) a blocked thread in Nt/2000/2003?
regards
Deepu.L.R
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
Killing threads on deadlock? Maybe it is better to catch all deadlocks
during debugging?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 29, 2004 8:27 PM
Subject: RE: [ntdev] Gracefully killing a blocked thread
> Yet that may not help if I get into a situation where there’s a potential
> deadlock that I may want to rollback by killing one of the deadlocked
> threads. That synchronization object may not be mine, yet my thread is hung
> on it, now what ?
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> Sent: Thursday, January 29, 2004 11:39 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Gracefully killing a blocked thread
>
>
> Presumably you would have an “error” or “abort” synchronization object
> that the thread is waiting on in addition to whatever other objects it’s
> waiting on.
>
> Chuck
>
> ----- Original Message -----
> From: “Moreira, Alberto”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, January 29, 2004 11:18 PM
> Subject: RE: [ntdev] Gracefully killing a blocked thread
>
>
> > So, if the reason for the blocking has crashed and we know that the
> thread
> > is never going to be unblocked, should it stay there forever like a
> zombie ?
> >
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
> Shatskih
> > Sent: Thursday, January 29, 2004 11:09 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Gracefully killing a blocked thread
> >
> >
> >
> > No. The thread is blocked for a reason, and, if the reason did not
> > occur, then it must stay waiting.
> >
> > Note that TerminateThread is a bad API (it causes the user stack
> of the
> > thread to go leak), practically never useful. Why ever terminating a
> thread
> > inside the alive process which continue to run?
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com mailto:xxxxx
> > http://www.storagecraft.com http:
> >
> >
> > ----- Original Message -----
> > From: Deepu.L.R mailto:xxxxx
> > To: Windows System Software Devs Interest
> mailto:xxxxx List
> >
> > Sent: Thursday, January 29, 2004 1:47 PM
> > Subject: [ntdev] Gracefully killing a blocked thread
> >
> > hi all,
> >
> > Is there any way to gracefully terminate (other than using
> > TerminateThread) a blocked thread in Nt/2000/2003?
> >
> > regards
> > Deepu.L.R
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > http:
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > mailto:xxxxx
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only.
> It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
chuck,
suppose the situation is like this. i am starting a synchronous IO
operation inside the thread (like socket recv() operation with having no
timeout set) and due to some reason it is not getting completed. ie, the
thread is blocked in the io operation but not in a WaitForSingleObject()
call.
In such a situation whether the below described method will work? or is
there any other work around?
or can we conclude by stating that - in NT/2000/2003 there is no way to
terminate a thread gracefully ?
thanks to all …
Deepu.L.R
----- Original Message -----
From: “Chuck Batson”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 29, 2004 11:21 PM
Subject: Re: [ntdev] Gracefully killing a blocked thread
> You should have a sync. object that is yours, a unique one per thread
> if necessary (i.e. if you want per-thread abortion control), that is
> used to abort any and all waits in a thread. The point being that your
> thread should never be able to hang indefinitely on any particular wait
> (because you can exit any particular wait by signalling the appropriate
> abort sync. object), and give the thread a chance to clean up before
> terminating.
>
> Chuck
>
> ----- Original Message -----
> From: “Moreira, Alberto”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, January 30, 2004 12:27 AM
> Subject: RE: [ntdev] Gracefully killing a blocked thread
>
>
> > Yet that may not help if I get into a situation where there’s a
> potential
> > deadlock that I may want to rollback by killing one of the deadlocked
> > threads. That synchronization object may not be mine, yet my thread is
> hung
> > on it, now what ?
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> > Sent: Thursday, January 29, 2004 11:39 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Gracefully killing a blocked thread
> >
> >
> > Presumably you would have an “error” or “abort” synchronization object
> > that the thread is waiting on in addition to whatever other objects
> it’s
> > waiting on.
> >
> > Chuck
> >
> > ----- Original Message -----
> > From: “Moreira, Alberto”
> > To: “Windows System Software Devs Interest List”
> > Sent: Thursday, January 29, 2004 11:18 PM
> > Subject: RE: [ntdev] Gracefully killing a blocked thread
> >
> >
> > > So, if the reason for the blocking has crashed and we know that the
> > thread
> > > is never going to be unblocked, should it stay there forever like a
> > zombie ?
> > >
> > >
> > > Alberto.
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
> > Shatskih
> > > Sent: Thursday, January 29, 2004 11:09 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Gracefully killing a blocked thread
> > >
> > >
> > >
> > > No. The thread is blocked for a reason, and, if the reason did
> not
> > > occur, then it must stay waiting.
> > >
> > > Note that TerminateThread is a bad API (it causes the user stack
> > of the
> > > thread to go leak), practically never useful. Why ever terminating a
> > thread
> > > inside the alive process which continue to run?
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com mailto:xxxxx
> > > http://www.storagecraft.com http:
> > >
> > >
> > > ----- Original Message -----
> > > From: Deepu.L.R mailto:xxxxx
> > > To: Windows System Software Devs Interest
> > mailto:xxxxx List
> > >
> > > Sent: Thursday, January 29, 2004 1:47 PM
> > > Subject: [ntdev] Gracefully killing a blocked thread
> > >
> > > hi all,
> > >
> > > Is there any way to gracefully terminate (other than using
> > > TerminateThread) a blocked thread in Nt/2000/2003?
> > >
> > > regards
> > > Deepu.L.R
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > http:
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > mailto:xxxxx
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > xxxxx@compuware.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee
> only.
> > It
> > > contains information that may be confidential. Unless you are the
> > named
> > > addressee or an authorized designee, you may not copy or use it, or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only.
> It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@m2comsys.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
You would have to perform your I/O asynchronously. You would then wait
on two events, one for I/O completion and one for abortion. In your
asynch I/O completion callback, signal the I/O completion event. In the
event the I/O never completes, some other “knowledgable entity” (say,
another thread) can signal the abortion event. If you have no other
“knowledgable entity” or prefer a timeout approach, then you would use a
timeout value while waiting for the I/O completion event, and handle the
timeout condition appropriately.
If you’re dealing with code you don’t have control over (i.e., a
third-party library), and there is the potential for deadlock, then the
code is broken and you need to get the vendor to fix it.
Chuck
----- Original Message -----
From: “Deepu.L.R”
To: “Windows System Software Devs Interest List”
Sent: Friday, January 30, 2004 12:42 PM
Subject: Re: [ntdev] Gracefully killing a blocked thread
> chuck,
>
> suppose the situation is like this. i am starting a synchronous IO
> operation inside the thread (like socket recv() operation with having
no
> timeout set) and due to some reason it is not getting completed. ie,
the
> thread is blocked in the io operation but not in a
WaitForSingleObject()
> call.
>
> In such a situation whether the below described method will work? or
is
> there any other work around?
>
> or can we conclude by stating that - in NT/2000/2003 there is no way
to
> terminate a thread gracefully ?
>
> thanks to all …
> Deepu.L.R
>
>
>
>
> ----- Original Message -----
> From: “Chuck Batson”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, January 29, 2004 11:21 PM
> Subject: Re: [ntdev] Gracefully killing a blocked thread
>
>
> > You should have a sync. object that is yours, a unique one per
thread
> > if necessary (i.e. if you want per-thread abortion control), that is
> > used to abort any and all waits in a thread. The point being that
your
> > thread should never be able to hang indefinitely on any particular
wait
> > (because you can exit any particular wait by signalling the
appropriate
> > abort sync. object), and give the thread a chance to clean up before
> > terminating.
> >
> > Chuck
> >
> > ----- Original Message -----
> > From: “Moreira, Alberto”
> > To: “Windows System Software Devs Interest List”
> > Sent: Friday, January 30, 2004 12:27 AM
> > Subject: RE: [ntdev] Gracefully killing a blocked thread
> >
> >
> > > Yet that may not help if I get into a situation where there’s a
> > potential
> > > deadlock that I may want to rollback by killing one of the
deadlocked
> > > threads. That synchronization object may not be mine, yet my
thread is
> > hung
> > > on it, now what ?
> > >
> > > Alberto.
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Batson
> > > Sent: Thursday, January 29, 2004 11:39 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Gracefully killing a blocked thread
> > >
> > >
> > > Presumably you would have an “error” or “abort” synchronization
object
> > > that the thread is waiting on in addition to whatever other
objects
> > it’s
> > > waiting on.
> > >
> > > Chuck
> > >
> > > ----- Original Message -----
> > > From: “Moreira, Alberto”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Thursday, January 29, 2004 11:18 PM
> > > Subject: RE: [ntdev] Gracefully killing a blocked thread
> > >
> > >
> > > > So, if the reason for the blocking has crashed and we know that
the
> > > thread
> > > > is never going to be unblocked, should it stay there forever
like a
> > > zombie ?
> > > >
> > > >
> > > > Alberto.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
> > > Shatskih
> > > > Sent: Thursday, January 29, 2004 11:09 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: Re: [ntdev] Gracefully killing a blocked thread
> > > >
> > > >
> > > >
> > > > No. The thread is blocked for a reason, and, if the reason
did
> > not
> > > > occur, then it must stay waiting.
> > > >
> > > > Note that TerminateThread is a bad API (it causes the user
stack
> > > of the
> > > > thread to go leak), practically never useful. Why ever
terminating a
> > > thread
> > > > inside the alive process which continue to run?
> > > >
> > > > Maxim Shatskih, Windows DDK MVP
> > > > StorageCraft Corporation
> > > > xxxxx@storagecraft.com mailto:xxxxx
> > > > http://www.storagecraft.com http:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Deepu.L.R mailto:xxxxx
> > > > To: Windows System Software Devs Interest
> > > mailto:xxxxx List
> > > >
> > > > Sent: Thursday, January 29, 2004 1:47 PM
> > > > Subject: [ntdev] Gracefully killing a blocked thread
> > > >
> > > > hi all,
> > > >
> > > > Is there any way to gracefully terminate (other than using
> > > > TerminateThread) a blocked thread in Nt/2000/2003?
> > > >
> > > > regards
> > > > Deepu.L.R
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > > http:
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > > mailto:xxxxx
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > > xxxxx@compuware.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > >
> > > >
> > > >
> > > > The contents of this e-mail are intended for the named addressee
> > only.
> > > It
> > > > contains information that may be confidential. Unless you are
the
> > > named
> > > > addressee or an authorized designee, you may not copy or use it,
or
> > > disclose
> > > > it to anyone else. If you received it in error please notify us
> > > immediately
> > > > and then destroy it.
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > xxxxx@compuware.com
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee
only.
> > It
> > > contains information that may be confidential. Unless you are the
> > named
> > > addressee or an authorized designee, you may not copy or use it,
or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@m2comsys.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
> or can we conclude by stating that - in NT/2000/2003 there is no way to
terminate a thread gracefully ?
No, the thread can only terminate itself. You can terminate a process full of
threads by KILL or Task Manager though.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> You would have to perform your I/O asynchronously. You would then wait
on two events, one for I/O completion and one for abortion. In your
asynch I/O completion callback, signal the I/O completion event. In the
event the I/O never completes, some other “knowledgable entity” (say,
another thread) can signal the abortion event. If you have no other
Dirty a bit. You leave the real completion of the IRP to the time of thread
exit.
The more correct way is the following:
- you MUST ensure that the IO request you sent to the kernel is completed - be
it succeeded, failed, or cancelled. - the sign of “complete” is one of the following:
- signaled OVERLAPPED::hEvent
- calling the completion APC
- request taken by GetQueuedCompletionStatus
- for usual synchronous IO - the return from Read/Write/DeviceIoControl
function. - if you dislike the idea of waiting for too long, then CancelIo is the only
good way. It will ping the driver in a way so that your IRP will be completed
(cancelled).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
I got the impression he was asking from more of a user-mode perspective.
If not the case, he should defer to your answer. =^)
Chuck
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Friday, January 30, 2004 7:57 PM
Subject: Re: [ntdev] Gracefully killing a blocked thread
> > You would have to perform your I/O asynchronously. You would then
wait
> > on two events, one for I/O completion and one for abortion. In your
> > asynch I/O completion callback, signal the I/O completion event. In
the
> > event the I/O never completes, some other “knowledgable entity”
(say,
> > another thread) can signal the abortion event. If you have no other
>
> Dirty a bit. You leave the real completion of the IRP to the time of
thread
> exit.
>
> The more correct way is the following:
> - you MUST ensure that the IO request you sent to the kernel is
completed - be
> it succeeded, failed, or cancelled.
> - the sign of “complete” is one of the following:
> - signaled OVERLAPPED::hEvent
> - calling the completion APC
> - request taken by GetQueuedCompletionStatus
> - for usual synchronous IO - the return from
Read/Write/DeviceIoControl
> function.
> - if you dislike the idea of waiting for too long, then CancelIo is
the only
> good way. It will ping the driver in a way so that your IRP will be
completed
> (cancelled).
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Since you brought up the case of a socket recv(), I
will just answer that …Create Non-blocking socket,
use select() with a reasonable timeout and call
WSARecv()when the socket has data to be read…
In this way even if there is an I/O failure your
thread will fall through and exit…
Microsoft has gone in lengths to provide
Async/non-blocking APIs for most of the I/O…Some of
the blocking APIs are still there for legacy or in
this case be BSD compatible…
Same with TerminateThread()…This is one API MS
wishes it never documented in the first place…
Your posting was more generic…Probably you can state
what your trying to do and what APIs your using and
the folks in the list can help you out…
An app that needs TerminateThread() to accomplish its
functionality needs redesign. Period…
— “Deepu.L.R” wrote:
> chuck,
>
> suppose the situation is like this. i am
> starting a synchronous IO
> operation inside the thread (like socket recv()
> operation with having no
> timeout set) and due to some reason it is not
> getting completed. ie, the
> thread is blocked in the io operation but not in a
> WaitForSingleObject()
> call.
>
> In such a situation whether the below described
> method will work? or is
> there any other work around?
>
> or can we conclude by stating that - in NT/2000/2003
> there is no way to
> terminate a thread gracefully ?
>
> thanks to all …
> Deepu.L.R
>
>
>
>
> ----- Original Message -----
> From: “Chuck Batson”
> To: “Windows System Software Devs Interest List”
>
> Sent: Thursday, January 29, 2004 11:21 PM
> Subject: Re: [ntdev] Gracefully killing a blocked
> thread
>
>
> > You should have a sync. object that is yours, a
> unique one per thread
> > if necessary (i.e. if you want per-thread abortion
> control), that is
> > used to abort any and all waits in a thread. The
> point being that your
> > thread should never be able to hang indefinitely
> on any particular wait
> > (because you can exit any particular wait by
> signalling the appropriate
> > abort sync. object), and give the thread a chance
> to clean up before
> > terminating.
> >
> > Chuck
> >
> > ----- Original Message -----
> > From: “Moreira, Alberto”
>
> > To: “Windows System Software Devs Interest List”
>
> > Sent: Friday, January 30, 2004 12:27 AM
> > Subject: RE: [ntdev] Gracefully killing a blocked
> thread
> >
> >
> > > Yet that may not help if I get into a situation
> where there’s a
> > potential
> > > deadlock that I may want to rollback by killing
> one of the deadlocked
> > > threads. That synchronization object may not be
> mine, yet my thread is
> > hung
> > > on it, now what ?
> > >
> > > Alberto.
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On
> Behalf Of Chuck Batson
> > > Sent: Thursday, January 29, 2004 11:39 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Gracefully killing a
> blocked thread
> > >
> > >
> > > Presumably you would have an “error” or “abort”
> synchronization object
> > > that the thread is waiting on in addition to
> whatever other objects
> > it’s
> > > waiting on.
> > >
> > > Chuck
> > >
> > > ----- Original Message -----
> > > From: “Moreira, Alberto”
>
> > > To: “Windows System Software Devs Interest List”
>
> > > Sent: Thursday, January 29, 2004 11:18 PM
> > > Subject: RE: [ntdev] Gracefully killing a
> blocked thread
> > >
> > >
> > > > So, if the reason for the blocking has crashed
> and we know that the
> > > thread
> > > > is never going to be unblocked, should it stay
> there forever like a
> > > zombie ?
> > > >
> > > >
> > > > Alberto.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com]On
> Behalf Of Maxim S.
> > > Shatskih
> > > > Sent: Thursday, January 29, 2004 11:09 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: Re: [ntdev] Gracefully killing a
> blocked thread
> > > >
> > > >
> > > >
> > > > No. The thread is blocked for a reason,
> and, if the reason did
> > not
> > > > occur, then it must stay waiting.
> > > >
> > > > Note that TerminateThread is a bad API (it
> causes the user stack
> > > of the
> > > > thread to go leak), practically never useful.
> Why ever terminating a
> > > thread
> > > > inside the alive process which continue to
> run?
> > > >
> > > > Maxim Shatskih, Windows DDK MVP
> > > > StorageCraft Corporation
> > > > xxxxx@storagecraft.com
> mailto:xxxxx
> > > > http://www.storagecraft.com
> http:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Deepu.L.R mailto:xxxxx
> > > > To: Windows System Software Devs Interest
> > > mailto:xxxxx List
> > > >
> > > > Sent: Thursday, January 29, 2004 1:47 PM
> > > > Subject: [ntdev] Gracefully killing a blocked
> thread
> > > >
> > > > hi all,
> > > >
> > > > Is there any way to gracefully terminate
> (other than using
> > > > TerminateThread) a blocked thread in
> Nt/2000/2003?
> > > >
> > > > regards
> > > > Deepu.L.R
> > > > —
> > > > Questions? First check the Kernel Driver FAQ
> at
> > > > http://www.osronline.com/article.cfm?id=256
> > > > http:
> > > >
> > > > You are currently subscribed to ntdev as:
> xxxxx@storagecraft.com
> > > > mailto:xxxxx
> > > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ
> at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > > xxxxx@compuware.com
> > > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > >
> > > >
> > > >
> > > >
> > > > The contents of this e-mail are intended for
> the named addressee
> > only.
> > > It
> > > > contains information that may be confidential.
> Unless you are the
> > > named
> > > > addressee or an authorized designee, you may
> not copy or use it, or
> > > disclose
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>
> will just answer that …Create Non-blocking socket,
use select() with a reasonable timeout and call
WSARecv()when the socket has data to be read…
Unscalable.
The scalable hi-perf way is - create the overlapped socket, and throw a lot of
ReadFiles to it. Close the socket when you need it no more - this will fail all
these reads.
An app that needs TerminateThread() to accomplish its
functionality needs redesign. Period…
Agree.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
As far as I know, every system that has purported to include the
equivalent of TerminateThread has later disavowed all knowledge of the
action. It looks oh-so-sensible on a piece of paper, and then you try to
figure how to make it work.
The best you can do is an APC-type mechanism (what we called ‘Ring
Alarm’ on Multics) which allows the kernel to bust a thread out of any
kernel wait-state and cause it to deliver a signal on return to the user
environment. This is good enough for any half-decently-designed
application. Actually murdering the thread is bound to leak something
somewhere, and a system that leaks is, in the long run, just a sick as a
system with a thread stuck in a system call.
hi all…
thanks for all the replies…
Max,Chuck,benson
I asked the question in the usermode point of view and it is a generic
question. I understood that the usage of TerminateThread() is not encouraged
and its disadvantages.
The best you can do is an APC-type mechanism (what we called ‘Ring
Alarm’ on Multics) which allows the kernel to bust a thread out of any
kernel wait-state and cause it to deliver a signal on return to the user
environment. This is good enough for any half-decently-designed
yes, i am asking whether windows supports anything as said above which will
invoke a thread out of any kernal wait state?[this is generic question and i
am not trying find solution for a particular problem]
thanks
Deepu.L.R
I can almost surely predict that 5 to 10 yrs from now, we from the home
users point of view would not even talk about processes and threads.
We are almost at a price point, necessity point where home pc ( or Mac
type)
is almost a necessity, and does not have any nostaligia, where U know what
you
doing with my cmd line or performance pannel. Network will be even more
faster, cooperative with
different protocols, and many many little prick like me would love to pump
in
code that would try to dispatch resource hogging entity to entice their
cynical mind(s).
Do I have to belive that those future home pc would not be able to tackle
these ?
No, definitely not. Does not matter how many processors or how big the
memory is for that matter.
This is so obvious a feature ( or lack thereof ) that I bet most of the OS
vendor
already know how to handle it. Might not be straight shooting theads …
So some of the finest brains (who are snooping the ether …) might be
smiling about our discussion, and
saying boy, Prokash we thought you are stupid, now you are confirmed moron
:-). We all know how to tackle
this !!!.
-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of benson margulies
Sent: Friday, January 30, 2004 6:01 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Gracefully killing a blocked thread
As far as I know, every system that has purported to include the
equivalent of TerminateThread has later disavowed all knowledge of the
action. It looks oh-so-sensible on a piece of paper, and then you try to
figure how to make it work.
The best you can do is an APC-type mechanism (what we called ‘Ring
Alarm’ on Multics) which allows the kernel to bust a thread out of any
kernel wait-state and cause it to deliver a signal on return to the user
environment. This is good enough for any half-decently-designed
application. Actually murdering the thread is bound to leak something
somewhere, and a system that leaks is, in the long run, just a sick as a
system with a thread stuck in a system call.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Deepu,
If you want to terminate the thread which is blocked in the recv() call then just close the socket using the call closesocket() from other thread. The Thread which is waitin on that socket will be out of recv with error code. If you are using terminate thread i’ll suggest u not to use that reason being “This call doesent free the kernel resources of the thread till the process is up, so it is indirect memory leak :O”.
Good Luck,
From: “Deepu.L.R”
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re: [ntdev] Gracefully killing a blocked thread
>Date: Sat, 31 Jan 2004 09:17:32 +0530
>
>hi all…
>
>thanks for all the replies…
>
>Max,Chuck,benson
>
>I asked the question in the usermode point of view and it is a generic
>question. I understood that the usage of TerminateThread() is not encouraged
>and its disadvantages.
>
> > The best you can do is an APC-type mechanism (what we called ‘Ring
> > Alarm’ on Multics) which allows the kernel to bust a thread out of any
> > kernel wait-state and cause it to deliver a signal on return to the user
> > environment. This is good enough for any half-decently-designed
>
>yes, i am asking whether windows supports anything as said above which will
>invoke a thread out of any kernal wait state?[this is generic question and i
>am not trying find solution for a particular problem]
>
>thanks
>Deepu.L.R
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Games, MMS cards, ringtones. Operator logos, picture messages & more. Jazz up your mobile!