Re: [NTDEV] Queue Management

> “Gary Little” wrote in message news:xxxxx@ntdev…
> to know there is a big enough presence in the development community that
> would use such an extension.
>

OK, guys. It took a while (mostly it took a while for me to read this) but
I got an answer on this from “Microsoft”:

It turns out that this addition has been discussed and considered in some
depth in the past. The consensus is that ExInterlockedRemoveEntryList() can
only be used correctly in a very small number of situations. There just
aren’t that many cases when you know for sure that the entry is going to be
on the list, without actually traversing the list. For those few cases when
you CAN be sure, it’s no more overhead to lock the list, remove the entry
with RemoveEntryList(), and then drop the lock. Which is what this function
would do in any case.

Balancing this is the fact that this function could very easily be subject
to unintentional misuse. I think you’ll agree that few enough people think
through the impact of simultaneous access to their data structures as it is.
Having an ExInterlockedRemoveEntryList() seems like an invitation for people
to shoot themselves in the foot. No, not everybody. But this function does
seem to have a greater propensity for potential misuse than most.

So… we’ve asked, and we’ve gotten an anwer. Microsoft isn’t going to add
ExInterlockedRemoveEntryList to the kernel. You can disagree with the
result, or the reasoning given, if you like. But at least you know that
somebody asked, and the relevant developers at Microsoft were sufficiently
interested to provide a detailed response, the essence of which I have now
passed along to you.

I hope that helps,

Peter


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