Recent

Author Topic: Suspend/Resume/CloseThread and TThreadId  (Read 2893 times)

440bx

  • Hero Member
  • *****
  • Posts: 4994
Suspend/Resume/CloseThread and TThreadId
« on: May 25, 2024, 03:08:12 pm »
Hello,

I just noticed the following definitions in thread.inc
Code: Pascal  [Select][+][-]
  1. function  SuspendThread (threadHandle : TThreadID) : dword;
  2. function  ResumeThread  (threadHandle : TThreadID) : dword;
  3. function  CloseThread   (threadHandle : TThreadID) : dword;
  4.  
where TThreadID is defined in sysosh.inc as
Code: Pascal  [Select][+][-]
  1.   TThreadID = DWord;
I believe this yields an incorrect definition because these thread functions, and many others declared as taking a TThreadID, take a THANDLE which in 64bit is 64 bit wide, not 32 bit.

This is important because in 64bit the TThreadId definition can cause the upper 32 bits of the handle to be truncated away.

Have I missed something or are these definitions working only due to sheer luck ?

Comments welcome.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Fibonacci

  • Hero Member
  • *****
  • Posts: 650
  • Internal Error Hunter
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #1 on: May 25, 2024, 04:02:32 pm »
AFAIK its thread ID, not the handle, and these functions you listed actually take the ID not the handle as a param
« Last Edit: May 25, 2024, 04:04:47 pm by Fibonacci »

ASerge

  • Hero Member
  • *****
  • Posts: 2376
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #2 on: May 25, 2024, 04:10:12 pm »
AFAIK its thread ID, not the handle, and these functions you listed actually take the ID not the handle as a param
No, it really is. There is a loss of bitness. From systhrd.inc:
Code: Pascal  [Select][+][-]
  1.     function  SysSuspendThread (threadHandle : TThreadID) : dword;
  2.     begin
  3.       SysSuspendThread:=WinSuspendThread(threadHandle); // WinSuspendThread equal kernel SuspendThread
  4.     end;
Fortunately, this is not essential (so far). In the current implementation of Windows HANDLE is usually an index in the internal table of descriptors. I.e., in reality, even Word is enough.

Fibonacci

  • Hero Member
  • *****
  • Posts: 650
  • Internal Error Hunter
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #3 on: May 25, 2024, 04:15:07 pm »
You're right, I just checked and the thread handle is really low number

440bx

  • Hero Member
  • *****
  • Posts: 4994
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #4 on: May 25, 2024, 04:42:37 pm »
Fortunately, this is not essential (so far). In the current implementation of Windows HANDLE is usually an index in the internal table of descriptors. I.e., in reality, even Word is enough.
Yes, basically sheer luck.  If MS were to change how that handle is created, e.g, setting some bits to indicate some characteristics the O/S might want to save in the handle, those definitions may no longer work.

This is not a far fetched idea, MS does currently use some bits in some handles to indicate features/properties of the item represented by the handle, e.g, handles returned by LoadLibraryEx (they use the bottom two bits to indicate the mapping format.)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12032
  • FPC developer.
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #5 on: May 25, 2024, 05:53:03 pm »
sha1: 7957c349407241e8135af138a68621d4cc9ccea3

    * change tthreadid to thandle, as the used functions for threadid in systhrd all use HANDLE.
    Marco Van de Voort authored just now

Please verify your win64 apps with trunk, and then we can maybe still merge it before 3.2.4
« Last Edit: May 25, 2024, 05:55:52 pm by marcov »

440bx

  • Hero Member
  • *****
  • Posts: 4994
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #6 on: May 25, 2024, 06:20:24 pm »
Thank you Marco.

I understand that most Windows handles are just indexes into internal tables (as Serge correctly pointed out) but, truncating 32 bits away in 64bit programs isn't a source of comfort.

Thank you for the quick response to the issue.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 2376
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #7 on: May 26, 2024, 04:17:08 am »
To be more precise, it is not the indexes, but the offsets in the table. Therefore, it is a multiple of 4 bytes. Even for x64.

440bx

  • Hero Member
  • *****
  • Posts: 4994
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #8 on: May 26, 2024, 09:40:54 am »
To be more precise, it is not the indexes, but the offsets in the table. Therefore, it is a multiple of 4 bytes. Even for x64.
It depends on the type of handle.

For instance, window handles are not multiples of 4, they seem to be multiples of 2.  There is no obvious pattern in their value distribution, such as sequentially increasing values depending on creation time.

The bottom line is that it would be unwise to rely on a handle being an index into an internal table because some handles are definitely not direct indexes into some table. In the case of a window handle, it is ok to rely on it being a maximum of 32 bit (even if a 64 bit window handle has the upper dword set to some value - it can be set to zero without any side effects.)  That cannot be said of other handles, particularly module handles that are simply an address in memory (sometimes massaged a little as LoadLibraryEx may do.)

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12032
  • FPC developer.
Re: Suspend/Resume/CloseThread and TThreadId
« Reply #9 on: May 26, 2024, 11:26:33 am »
GDI handles are probably from the desktop heap, which is limited and can run out of space. I had a run in with it once :-)

 

TinyPortal © 2005-2018