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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
