On 03/06/2013 01:43 PM, Sven Barth wrote:
And how does one the "current" TThread?
Since a few weeks: TThread.CurrentThread ;)
This does in fact use a threadvar:
threadvar
{ the instance of the current thread; in case of an external thread
this is
Nil until TThread.GetCurrentThread was called once (the RTLs need
to ensure
that threadvars are initialized with 0!) }
CurrentThreadVar: TThread;
and (unless the compiler optimizes this out) even accesses it twice:
if not Assigned(CurrentThreadVar) then
CurrentThreadVar := TExternalThread.Create;
Result := CurrentThreadVar;
From within the TThread object, simply using Self seems more
appropriate unless there is a chance that the same TThread instance is
used for multiple OS-Threads. I don't know if/how this is possible.
From "outside" I feel that AnyThread.GetCurrentThread does not make
much senses.
When doing "TThread.GetCurrentThread" as a class function I think I
should get "self" of same when I am in the code that is called from
"Execute" of some TThread instance. I don't see what I want to see when
I'm not.
The code seems to try to avoid the case that a no TThread instance when
GetCurrentThread is called as a a class function. I don't know if/how
this is sensible.
Using CurrentThread only seems sensible within the the code of a
component that has been called by the code of a TThread instance. But
here using an appropriate back-link property can easily be used to avoid
accessing the threadvar. (or using CurrentThread once to set a
property and then just accessing same.) But this of course needs to be
done in user code and the RTL can't force it.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
