OK, I’ll have one final post on this topic, and then I’m done.
“Gary Little” wrote in message news:xxxxx@ntdev…
>
> of error … then realized you were actually supportive.
>
Duh! I wouldn’t have advocated for it with the developers if I wasn’t
“supportive”, Gary!!
>
> If I understood your earlier post correctly, the development team does not
> want to provide such a function because it could to easily be abused.
>
No, I don’t think that’s what I said. Well, that’s not what I meant to say.
Or… What I TRIED to say was the developers feel that this function would
be easily “subject to unintentional misuse.” Providing the function could
quite easily mislead folks (who do not really, fully, understand
synchronization or who do not take the time to fully think through their
designs) into thinking that removal of mid-list elements from an interlocked
list is an inherently “safe” thing to do… just like removing an element
from the front of back of the list. This this is not safe is not
necessarily intuitively obvious. You’ve gotta admit, they have a point
there.
In addition, this function is properly useful only in very narrow
circumstances, all of which can be handled by locking the list yourself (see
below).
So, the developers have decided that the risk does not outweigh the benefit
in this case.
Finally, it was made abundantly clear to me that adding
ExInterlockedRemoveEntryList to the kernel is not an issue that is likely to
be reconsidered, at least in my lifetime.
I did NOT know, until I read your post, that
KeAcquireSpinLockRaiseToSynch(…) is no longer exported. Ugh!. Well, that
breaks some of MY code, for sure. Of course, this function was never
documented, and driver verifier would fail you if you used it. So, I’m
thinkin’ we’re not in a very good position to advocate for its return, you
know?
Peter
OSR
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com