[fpc-pascal] GetCurrentThreadID under FreeBSD vs Linux

[Ewald]

Hello,

I had the exact same issue when writing debug info in my code. Easy to
solve I think. Just define a macro at the top of the unit like this:

    {$macro on}
    {$define Debug_ThreadSelf:= ptruint(GetCurrentThreadID)}

And then change all FmtStr lines to something like

    FmtStr(LThreadID, '%.4d', [Debug_ThreadSelf]);

And if you don't like macro's, just change all FmtStr lines into

    FmtStr(LThreadID, '%.4d', [ptruint(GetCurrentThreadID)]);

It can be that `ptruint` is defined in `unixtype`, but I don't know for
sure.


Once upon a time, on 02/08/2013 03:40 PM to be precise, Graeme
Geldenhuys said:
> Hi,
>
> Under Linux and Windows I have the following code which works fine.
>
> var
>   LThreadID: string;
> begin
>   FmtStr(LThreadID, '%.4d', [GetCurrentThreadID]);
>
>
> Under FreeBSD (64-bit) that failed with a EConvertError in the unit
> tests and the compiler gave a message of 'Invalid argument index in
> format "%.4d"'
>
> Navigating the code to see how TThreadID is defined, I found this for
> FreeBSD.
>
>   TThreadRec = record end;
>   TThreadID  = ^TThreadRec;
>
> So TThreadID is just a pointer to a record structure. Apparently getting
> a "real" thread ID/number is not as easy as under Linux. [Info from
> Google searches]. Under FreeBSD it seems that naming each thread with a
> string value is a more supported solution.
>
> I'm not so fussed about the exact ID per thread, so the pointer value
> will be fine. Windows uses a THandle and Linux uses a PtrUInt as the
> types for TThreadID.
>
> So would it be safe if I did the following in my code? For the Windows,
> Linux and FreeBSD platforms at least.
>
>   FmtStr(LThreadID, '%.4d', [PtrUInt(GetCurrentThreadID)]);
>
>
> I've tested the PtrUInt() cast under FreeBSD, Linux and Windows, and it
> seems to work fine.
>
>
> BTW:
> This code is only used to supply a thread id/value to a logging function
> (file, GUI, console etc) to help with debugging, or at least show which
> thread wrote what debug log entries. So it's not critical code.
>
>
>
> Regards,
>   - Graeme -
>


-- 
Ewald