In order not to steel yet another Thread topic I answer in a new thread....

On 06/27/2014 11:35 AM, Mattias Gaertner wrote in "Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?":

I just re-checked and found that in thread.inc the "waiting and waking" is done by calls to callback variables such as "rtleventWaitFor" and "rtleventSetEvent".

When initializing, these variables are filled with the appropriate "OS-depending" function pointers by code in the file "systhrd.inc" located in the OS-appropriate folder.

I understand that the "rtlevent..." stuff and the method to append an event to the TThread queue is private to TThread and hence I can't use this for TTimer and TApplication.QueueAsyncCall, Hence my only option (other than constructing an additional queue including an additional "OS-depending" "waiting and waking" mechanism) is using the timeout of CheckSynchronize (e.g. for TTimer), and TThread.Queue (e.g. for TApplication.QueueAsyncCall).

And this is what "technically" already seems to work rather nicely.

With that it will only work "officially" with the next release of the fpc rtl (no problem for me, but maybe preventing a "decent" patch to the "official" svn).

What can't be done without a modification in the fpc RTL is that this way TApplication.QueueAsyncCall will not be Queued when called from the main thread (no problem for me, but maybe preventing a "decent" patch to the "official" svn).

-Michael

"Michael Schnell" wrote

In order not to steel yet another Thread topic I answer in a new

thread....

On 06/27/2014 11:35 AM, Mattias Gaertner wrote in "Re: [Lazarus] nonlcl

basic issue: is codetools LCL dependent?":

> > >> handling the waiting and waking for both Queues simultaneously. This

(waiting and waking regarding the additional queue) needs arch depending code (as done in the GUI based Widget Types).

is done by calls to callback variables such as "rtleventWaitFor" and "rtleventSetEvent".

When initializing, these variables are filled with the appropriate

"OS-depending" function pointers by code in the file "systhrd.inc" located in the OS-appropriate folder.

I understand that the "rtlevent..." stuff and the method to append an

event to the TThread queue is private to TThread and hence I can't use this for TTimer and TApplication.QueueAsyncCall, Hence my only option (other than constructing an additional queue including an additional "OS-depending" "waiting and waking" mechanism) is using the timeout of CheckSynchronize (e.g. for TTimer), and TThread.Queue (e.g. for TApplication.QueueAsyncCall).

The TThreadManager.RTLEvent* procvars are available through analogous named RTLEvent* functions...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140710/f78004e3/attachment.html>

Thanks a lot for the pointer.

I'll take a look ASAP.
-Michael

OK.

I found the global function "GetThreadManager" and via it's result I seemingly can use the TThread Queue.

Maybe it's possible to avoid using TThread.Queue (and the said problems) by this.

Thanks,
-Michael

You should not need to use the thread manager. All functions (except the semaphore ones which are only implemented for cthreads) should be available by RTL functions. So don't use GetThreadManager if you don't need to.

Regards,
Sven

For a primary test I did e.g.:

   if GetThreadManager(CurrentThreadManager) then begin
CurrentBasicEventCreateHandler:=CurrentThreadManager.BasicEventCreate;
   end;
   if Assigned(CurrentBasicEventCreateHandler) then begin
     CurrentBasicEventCreateHandler(EventPointer, False, False,
'TestEvent');           /nonsense call to a "BasicEventCreateHandler"
function
   end;

Could you show me how to do an arch/OS independent call to the function that at runtime is pointed to by "CurrentBasicEventCreateHandler".

Thanks,
-Michael