[fpc-devel] StdOut capture for FPC RTL

[Jonas Maebe]

On 25 Nov 2010, at 20:15, Anton Kavalenka wrote:

> At 25.11.2010 19:57, Jonas Maebe wrote:
>> Actually, that won't work because the different threads will then  
>> work on a common buffer but with distinct pointers into it. A  
>> better solution is probably to do this in the intialisation code of  
>> each thread instead:
>>
>> {$ifdef unix}
>>   fpclose(ttextrec(stdout).handle);
>> {$elsif defined(MSWINDOWS)}
>>   { this is a copy of do_close() from the rtl, I don't know whether
>>     a new handle from a thread can actually have any of these  
>> values }
>>   if (handle<>  StdInputHandle) and
>>      (handle<>  StdOutputHandle) and
>>      (handle<>  StdErrorHandle) then
>>     CloseHandle(ttextrec(stdout).handle);
>> {$else}
>>   {$error Add support for this platform}
>> {$endif}
>>
>> ttextrec(stdout).handle:=myglobalstdouthandle;
>>
> That's unsuitable. I have lots of modules and lost of threads. Many  
> modules built with C++ runtime, others with C.

The C++ and C threads won't have their input/output handles replaced  
by default, since they are not started via the FPC RTL. The only  
exception is in case they call back into Pascal code and they are  
subsequently hooked by the RTL because the Pascal code (indirectly)  
accesses a threadvar.

Coincidentally, just the other day we were discussing introducing the  
ability to install hooks that will be called automatically whenever an  
external thread is hooked by the RTL (since the RTL has to initialise  
a bunch of things at such a point, so may user code). You could do  
whatever initialisation you need to do at that point.

I think we could extend such a callback mechanism to all threads,  
possibly with a boolean parameter indicating whether the thread was  
started via the FPC RTL or not in case the difference is important in  
some use cases.


Jonas