Dear All,
in my FSD I need to block Create IRPs for a long time. Now I want to
implement cancelling for those IRPs.
Because I cannot post the Create IRP I let the original thread wait until it
can proceed and I implemented I cancel routine which should awake the
waiting thread and tell him to complete the IRP.
What I now see is that the cancel routine is never called. Is this because
Create IRPs will never be cancelled or is it only possible to cancel pending
IRPs? Well, thinking twice about it it seems like its obvious: Because a
cancel routine usually completes the IRP, it cannot complete it if it is not
pending. However, all I want is to inform the waiting thread that it should not
wait any longer.
Beside the cancel mechanism is there another method to detect that the
originating process is going to die?
BTW: Would it be possible to pend create IRPs if I capture the user context
in the original thread?
Thanks,
Detlef.
–
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You CAN post a create IRP (but the calling thread is blocked by the
IO manager anyway). The user security context is embedded in the irp.
I’ve never had any luck allowing for the cancellation of create
irps, and I’m not sure it can be done. Empirical eveidence suggests it
cannot. Even if it could, the user mode apis for cancelling create irps are
handle based (and a handle has not been created yet!).
-----Original Message-----
From: xxxxx@gmx.de [mailto:xxxxx@gmx.de]
Sent: Thursday, April 19, 2001 7:49 AM
To: File Systems Developers
Subject: [ntfsd] Cancel Create IRPs?
Dear All,
in my FSD I need to block Create IRPs for a long time. Now I want to
implement cancelling for those IRPs.
Because I cannot post the Create IRP I let the original thread wait until it
can proceed and I implemented I cancel routine which should awake the
waiting thread and tell him to complete the IRP.
What I now see is that the cancel routine is never called. Is this because
Create IRPs will never be cancelled or is it only possible to cancel pending
IRPs? Well, thinking twice about it it seems like its obvious: Because a
cancel routine usually completes the IRP, it cannot complete it if it is not
pending. However, all I want is to inform the waiting thread that it should
not
wait any longer.
Beside the cancel mechanism is there another method to detect that the
originating process is going to die?
BTW: Would it be possible to pend create IRPs if I capture the user context
in the original thread?
Thanks,
Detlef.
–
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> What I now see is that the cancel routine is never called. Is this because
Create IRPs will never be cancelled or is it only possible to cancel
pending
No.
This is because the IRP cancellation must be executed by the same thread.
And the thread is blocked in KeWaitForSingleObject(…KernelMode, FALSE…)
What you need is not a cancel routine, but an interruptible wait.
You can do this by KeWaitForSingleObject(…UserMode, TRUE…) - be ready to
receive STATUS_ALERTED or STATUS_USER_APC return value which means “the wait
is interrupted”. You must return control from your code ASAP in this
condition, performing all necessary cleanup like failing the IRP.
Also note that this stuff is undocumented.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Sure. Create a system thread in the context of the process the IRP is
comming from and then have the thread to wait until you are ready to process
the request. Since you are holding the IRP for a long time, the delays in
creating the system thread should not be a problem.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@gmx.de
Sent: Thursday, April 19, 2001 4:49 AM
To: File Systems Developers
Subject: [ntfsd] Cancel Create IRPs?
Dear All,
in my FSD I need to block Create IRPs for a long time. Now I want to
implement cancelling for those IRPs.
Because I cannot post the Create IRP I let the original thread
wait until it
can proceed and I implemented I cancel routine which should awake the
waiting thread and tell him to complete the IRP.
What I now see is that the cancel routine is never called. Is this because
Create IRPs will never be cancelled or is it only possible to
cancel pending
IRPs? Well, thinking twice about it it seems like its obvious: Because a
cancel routine usually completes the IRP, it cannot complete it
if it is not
pending. However, all I want is to inform the waiting thread that
it should not
wait any longer.
Beside the cancel mechanism is there another method to detect that the
originating process is going to die?
BTW: Would it be possible to pend create IRPs if I capture the
user context
in the original thread?
Thanks,
Detlef.
–
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> What you need is not a cancel routine, but an interruptible wait.
You can do this by KeWaitForSingleObject(…UserMode, TRUE…) - be ready
to
receive STATUS_ALERTED or STATUS_USER_APC return value which means “the
wait
is interrupted”. You must return control from your code ASAP in this
condition, performing all necessary cleanup like failing the IRP.
Also note that this stuff is undocumented.
Thanks Max,
this seems to work at a first glance, but couldn’t there also be other User
APCs delivered to this thread?
Detlef.
–
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I’d advise against holding on to creates for lengthy periods of time.
RDR timeouts over network will be nasty, plus there are certain RDRs out
there
which hold locks during creates which can bring the perf. Of entire
system down.
You should investigate alternative means of deferring the work to
post-create, and
let the create succeed
-----Original Message-----
From: Detlef Golze [mailto:xxxxx@gmx.de]
Sent: Thursday, April 19, 2001 9:45 AM
To: File Systems Developers
Subject: [ntfsd] Re: Cancel Create IRPs?
What you need is not a cancel routine, but an interruptible wait.
You can do this by KeWaitForSingleObject(…UserMode, TRUE…) - be
ready
to
receive STATUS_ALERTED or STATUS_USER_APC return value which means
“the
wait
is interrupted”. You must return control from your code ASAP in this
condition, performing all necessary cleanup like failing the IRP. Also
note that this stuff is undocumented.
Thanks Max,
this seems to work at a first glance, but couldn’t there also be other
User APCs delivered to this thread?
Detlef.
–
GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> this seems to work at a first glance, but couldn’t there also be other
User
APCs delivered to this thread?
User APCs are called at the moment of returning to user mode, they will not
interrupt the kernel-mode code.
Thread termination is also a user APC.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com