> According to the help files in the *WIN2K DDK*, OBJ_KERNEL_HANDLE can
Yes. OBJ_KERNEL_HANDLE is w2k+.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> According to the help files in the *WIN2K DDK*, OBJ_KERNEL_HANDLE can
Yes. OBJ_KERNEL_HANDLE is w2k+.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Note: most uses of PsCreateSystemThread is to create your own
implementation of Ex/IoQueueWorkItem which is free from limitations. This is
how “event processing” is done.
There is very small number of other cases to use PsCreateSystemThread -
persistent security context is one of them.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> I wouldn’t use a timeout, but would let them sleep indefinitely and wake them
via KeSetEvent for termination.
>
>
> I have 16 different events of which 8 (no order) can occur simultaneously.
> This “can occur” is merely a possibility, not something I expect to happen
very often (or at all).
>
> Each thread would be dedicated to one event, but although I would enable
parallel processing of events, only one event instance at a time would be
allowed.
> If, for example, thread 1 is currently processing event 1, and event 1 occurs
again, the first instance of event 1 would be canceled and thread 1 would begin
processing the new instance.
>
> In my case, “processing events” means walking through an (variable) array of
instructions and taking appropriate actions.
> So, I could use one thread for all events. Every event would be granted one
instruction before switching to the next array.
> However, such an instruction could also include KeDelayExecutionThread for a
small, but variable interval, which would then affect the processing of all
events.
> A solution could be a substitution of KeDelayExecutionThread with
KeQueryInterruptTime, but this would essentially be a busy wait.
> As you can the, the biggest problems are those intentional delays which could
be desired.
>
> I hope I was able to make myself clear.
>
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, August 01, 2007 5:24 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsCreateSystemThread and the caller’s process context> I considered doing some tests under W2K,
Based upon my own experience, I can tell you that a call to PsCreateSystemThread() from non-system thread works just fine under W2K - a couple of years ago I worked on a project where a system thread had to be created in response to IOCTL that was originated the user app, i.e. to call PsCreateSystemThread() in context of a user thread. The whole thing was required to be working on all OS versions, starting from W2K SP0 up to XP SP2. It was thoroughly (and successfully) tested under all service packs of W2K, and did not pose a *slightest* problem anywhere…
Ah, now I remember we had exactly the same design in one driver. PsCreateSystemThread() called from IOCTL handler in context of user mode thread. Worked well for NT4, w2k and XP, all SPs. It should also work at Vista but I don’t remember if I ever tried it because we abandoned this driver.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]