Re: Cancel-safe without a thread?

here are things that you probably didn't consider
1) the cancel path acquired your cancel routine exactly when you tried to
dequeue. you must defer to the cancel routine
2) if you are using the PIRP pointer value as a cookie for retrieval, you
must realize that the original irp can be canceled/completed and a new PIRP
with same pointer value is sent to your driver and when you try to retrieve
the PIRP, you are getting the new one, not the old one.

yes, in the end it is a data structure and algorithm problem. It took a few
really smart folks in windows itself years to figure out all the weird
subtleties and races that can occur and how to handle them correctly. You
can choose to ignore that work and do it on your own, or you an choose to
use something that is already well tested and focus on the value add you
want to create in your driver. the same applies for
pnp/power/wmi/etc....you can choose to do it yourself and spend an initial
week implementing it and then many weeks later debugging weird issues, or
you can choose to use an already tested solution and use cycles elsewhere.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<BubbaGump> wrote in message
news:b3mlf259b4o4qjucc0n4cspsarq4leehlf@xxxxxxxxxx
On Fri, 01 Sep 2006 18:33:26 -0400, BubbaGump <> wrote:

Back on a more technical note, I got the impression (from the WDM
driver book) that cancel-safe queues required a dedicated thread to
de-queue each IRP, and now I'm reading about some sort of custom
DEVQUEUE structure the author came up with.

A dedicated thread seems like overhead, but I'd prefer to use the DDK
as much as possible. Do I really need a dedicated thread? It looks


Never mind. After looking at the manual way of doing cancellation in
the driver book, I see that it makes sense and it's what I'd use if I
didn't want a dedicated thread (none of the double-lock silliness I
was proposing).

I don't see what all the fuss was/is about (the warnings and hint of
horror stories). It's just another algorithm, with the type of subtle
timing conditions that should be expected in a low-level system
component. I had to think about it for a couple days before it made
sense, but I expect that occasionally from any code I write, or I
wouldn't want to write it.

When someone needs to implement any basic data structure there are
usually existing algorithms that have already been developed. If
those algorithms are decent then wise and smart people will tend to
use them, but that doesn't mean they have to be pressured into using
them. It's possible people who aren't wise enough to use an existing
algorithm or smart enough to develop a replacement shouldn't be doing
the work they're doing. I'm not fond of ignorance, fear, or
superstition.

I actually think now that cancel-safe queues are a little more
confusing than the manual way. The idea of having to supply functions
(insert, remove, lock) to be wrapped by similarly named functions just
to hide the act of cancellation (marking something as canceled,
de-queueing it, and completing it) seems silly, and that peek function
I find really mysterious. It'd be nice if the cancel-safe queue
library did the insert, remove, and lock itself without requiring any
user-supplied functions.



.

Relevant Pages

  • REPOST: Re: Q: How to test new hash algorithm?
    ... I realise that real and well known Hash algorithms are lightyears better than any thing I could cook up in a hurry - Never thought otherwise. ... Still remains with the task of inplimenting a new algorithm in a 'new' language. ... Subject: Cancel "Re: Q: How to test new hash algorithm?" ...
    (sci.crypt)
  • REPOST: division
    ... I need a c program or the algorithm to find the remainder of two large ... Control: cancel ...
    (sci.crypt)
Loading