this was not helped by my using Win32::Process::Info to dump all the system process details - it gives Handle and ProcessId with same value, and I assumed Handle meant Thread Handle, and that it was the same as Process Id if the process only had a single thread (i.e. I thought Handle == PID == TID).

I'm not sure why the 'handle' key returned from Win32::Process::Info is so labelled. From a quick inspection, it appears to the the same value as the 'ProcessId' in every case. It just appears to be a duplicate.

As I see it now, to change a thread priority :-

I need to generate a Duplicate Handle from within the running process.

Use this duplicate handle from within Perl to change the Thread Priority of the original thread.

1. As far as I am aware, there is no mechanism for obtaining a handle to a thread within another process.

   Update: It is possible to obtain a handle to a thread within another process, namely OpenThread(), but you must have a Win32 native TID (not a threads module TID).

2. Unless you have the source code for all the processes you are trying to affect, you will not be able to use DuplicateHandle() within those processes(*).

   Even if you do have the sources, you wouldn't be able to generate a duplicate thread handle for your Perl script's use without having a process handle to the Perl process. Catch22.

   And even if you arrange for all the processes you wish to modify to look for your Perl script and generate a duplicate for it, you would still need to communicate those to your Perl script.

3. Adjusting the priority of another process' threads is a really "Bad Idea".

   Actually, adjusting another process' priority class is not a great idea either, unless it is just a temporary measure and you set it back to it former value fairly soon afterwards.

   Even setting the priority (class) of your own process or threads to non-default values is not recommended unless you have very well thought through reasons for doing so, and those threads or processes are written to do tasks that require it, and are aware of their status.

   Eg. If you have a process that needs to respond very quickly to an event when it occurs, then running the thread waiting (on a semaphore or similar sleep-till-it happens mechanism--not polling!), for that event, then setting it's priority higher than normal can work. But once it becomes unblocked, it should either do what it has to do very quickly and go back to blocking, by handing the work off to a normal priority thread if it will take any time, or by dropping it's priority before doing the work.

   Multi-threaded processes rely upon the relative priority of their threads being well balanced commensurate with the types of work each thread is charged with doing. If you go around adjusting those priorities without understanding the balance required, you will probably render the processes, and possibly your system, defective or non-functional.

So the questions are: Why do you want to do this? What are you trying to achieve?

(*)Actually, there is a mechanism that involves injecting a thread into the other process using CreateRemoteThread(). This requires exceptional privileges, and is normally reserved for Debugger programs.