[fpc-devel] StdOut capture for FPC RTL

Anton Kavalenka anton.k at tut.by
Thu Nov 25 20:15:56 CET 2010


At 25.11.2010 19:57, Jonas Maebe wrote:
> On 25 Nov 2010, at 13:21, Jonas Maebe wrote:
>
>    
>> On 25 Nov 2010, at 12:24, Anton Kavalenka wrote:
>>
>>      
>>> What I have to do to properly initialize these defaults for new threads AFTER capturing StdOut?
>>>        
>> Store a copy of your stdout in a global variable, and after creating a new thread
>>
>>   close(stdout);
>>   stdout:=myglobalstdout;
>>
>> (and maybe the same for "output").
>>      
> 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;
>
>
> Jonas_______________________________________________
> fpc-devel maillist  -fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>    
That's unsuitable. I have lots of modules and lost of threads. Many 
modules built with C++ runtime, others with C.
Output goes from many places and many threads.
The task is to do inside process what the UNIX tee command does outside.

regards,
Anton





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20101125/9e27a9ba/attachment.html>


More information about the fpc-devel mailing list