in reply to Re^13: how to change process & thread priority on Win32 ?
in thread how to change process & thread priority on Win32 ?

Ah, you're right.. OpenThread apparently bridges that gap : "The handle returned by OpenThread can be used in any function that requires a handle to a thread, such as the wait functions, provided you requested the appropriate access rights. The handle is granted access to the thread object only to the extent it was specified in the dwDesiredAccess parameter". So my call sequence should be :-
Thread32First OpenThread SetThreadPriority
Does this look better ? Now I still need to make Process32First work...

Replies are listed 'Best First'.
Re^15: how to change process & thread priority on Win32 ?
by BrowserUk (Patriarch) on Dec 13, 2005 at 05:48 UTC

    Sorry, but you are still borked. OpenThread() takes a thread ID, but as I mentioned above, thread IDs are only unique within their process. If you try to call it with thread ID == 2 (say), it will attempt to open thread 2 of the current process, in this case, perl.exe (which may or may not exist), not the process you are attempting to change.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      I did get the code to work.. seems to me that details of threads of process x can indeed be changed from within process y - code follows :-
      # set first thread for $pid to $hThreadPriority my $pid = 952; my $hThreadPriority = 0; my $retcode; my $hThreadSnap; my $hThread; my $Point; use Data::Dumper; use strict; use Win32::API; Win32::API->Import( 'Kernel32', q[ DWORD GetLastError( ) ] ); $retcode = Win32::API->Import( 'Kernel32', q[ HANDLE CreateToolhelp32Snapshot ( DWORD dwFlags, DWORD th32ProcessID ) ] ); print "import CreateToolhelp32Snapshot code $retcode \n"; use constant TH32CS_SNAPTHREAD => 0x4; $hThreadSnap=CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0); $retcode = GetLastError(); print "CreateToolhelp32Snapshot error code $retcode \n"; print "hThreadSnap = $hThreadSnap \n"; # typedef for THREADENTRY32 typedef Win32::API::Struct TE32 => qw{ DWORD dwSize; DWORD cntUsage; DWORD th32ThreadID; DWORD th32OwnerProcessID; LONG tpBasePri; LONG tpDeltaPri; DWORD dwFlags; }; $retcode = Win32::API->Import( 'Kernel32', q[ BOOL Thread32First ( HANDLE hSnapshot, LPTE32 lpte)]); print "import thread32first code $retcode \n"; $Point = Win32::API::Struct->new( 'TE32' ); $Point->{dwSize}=28; Thread32First($hThreadSnap, $Point); $retcode = GetLastError(); print "thread32first error $retcode \n"; print "pid = $Point->{th32OwnerProcessID} \n"; $retcode = Win32::API->Import( 'Kernel32', q[ BOOL Thread32Next ( HANDLE hSnapshot, LPTE32 lpte)]); print "import threadnext code $retcode \n"; until ( $Point->{th32OwnerProcessID} == $pid ) { Thread32Next($hThreadSnap, $Point); $retcode = GetLastError(); print "thread32next error $retcode \n"; print "pid = $Point->{th32OwnerProcessID} \n"; } $retcode = Win32::API->Import( 'Kernel32', q[HANDLE OpenThread( DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwThreadId ) ] ); print "import openthread code $retcode \n"; use constant THREAD_SET_INFORMATION => 0x0020; use constant THREAD_QUERY_INFORMATION => 0x0040; $hThread = OpenThread( THREAD_SET_INFORMATION|THREAD_QUERY_INFORMATION, 0, $Point->{th32ThreadID} ); $retcode = GetLastError(); print "openthread error code $retcode \n"; $retcode = Win32::API->Import( 'Kernel32', q[BOOL SetThreadPriority( HANDLE hThread, int nPriority ) ] ); print "import openthread code $retcode \n"; SetThreadPriority( $hThread, $hThreadPriority ); $retcode = GetLastError(); print "setthreadpriority error code $retcode \n";
        seems to me that details of threads of process x can indeed be changed from within process y

        Indeed, you are correct. Sorry for the misinformation. My confusion stemmed from the difference between threads TIDs and Win32 native TIDs. The former are unique within the system at any given time, whilst the latter are unrelated, process unique numbers created by the Perl.

        It would certainly make things simpler if there was a threads module call that would return the native TID directly. I'll look into how easily that could be provided and maybe offer a patch.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.