[fpc-devel] StdOut capture for FPC RTL

[Michael Van Canneyt]

On Fri, 26 Nov 2010, Jonas Maebe wrote:

>
> 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.

I think this is not bad; the question is whether we can do it on unix.
On Unix, we can currently only check when a threadvar is accessed.

Michael.