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
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
On 26 Nov 2010, at 11:11, Michael Van Canneyt wrote:
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.
The semantics of those callbacks would be that they are called as soon
as the RTL is initialised
On Fri, 26 Nov 2010, Jonas Maebe wrote:
On 26 Nov 2010, at 11:11, Michael Van Canneyt wrote:
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.
The semantics of those callbacks would be that they are
On Thu, November 25, 2010 18: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,
On 26 Nov 2010, at 18:59, Tomas Hajny wrote:
I'm not sure if closing the handle using the platform specific API is
actually a good idea here, because the RTL is probably not opening the
file in this case
You're right, so you don't even need that special code. Just change the handle
and
On Thu, 25 Nov 2010, Thaddy wrote:
On 24-11-2010 21:32, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Anton Kavalenka wrote: Get stdout handle (duplicate it
under linux),
create pipe,
replace the stdout (keeping the old stdout) for current process with write
handle of pipe,
There
In our previous episode, michael.vancann...@wisa.be said:
Michael.
You can write a classic pascal textfile device driver and assign
directly
to the global TEXT variables Input, Output and ErrOutput.
Don't know is this is threadsafe, though.
No, it will not be thread-safe. You'll
On Thu, 25 Nov 2010, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
Michael.
You can write a classic pascal textfile device driver and assign directly
to the global TEXT variables Input, Output and ErrOutput.
Don't know is this is threadsafe, though.
No, it will not be thread-safe. You'll have to do it over and over
again for
each thread.
I have some code by Peter Below on archive for that, that also works
on FPC win. The implementation part of that unit can be adapted for
nixen.
the file is called streamio.pas and can be easily found
On 25-11-2010 9:21, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
No, it will not be thread-safe. You'll have to do it over and over again for
each thread.
Just curious:Why not? I thought it was safe if you flushed before you created
threads?
Writing to
In our previous episode, Thaddy said:
I guess Marco is right: Just flush after thread operations.
On its own it is not threadsafe, I agree, but it might be a simple and
solid solution. *without* the rewrites :)
IIRC there is a pointer in the filetype that points into the buffer.
(bufptr).
On 25-11-2010 9:49, Marco van de Voort wrote:
solid solution. *without* the rewrites :)
IIRC there is a pointer in the filetype that points into the buffer.
(bufptr). Just copying that means they still point into the same pointer.
___
Yes, They (input,
On Thu, 25 Nov 2010, Thaddy wrote:
On 25-11-2010 9:49, Marco van de Voort wrote:
solid solution. *without* the rewrites :)
IIRC there is a pointer in the filetype that points into the buffer.
(bufptr). Just copying that means they still point into the same pointer.
On 25-11-2010 10:24, michael.vancann...@wisa.be wrote:
They are threadvars in trunk:
ThreadVar
ThreadID: TThreadID;
{ Standard In- and Output }
ErrOutput,
Output,
Input,
StdOut,
StdErr : Text;
Michael.
___
That's not Delphi
?? 25.11.2010 10:14, michael.vancann...@wisa.be ???(??):
On
Writing to the files is thread-safe, but in new threads, the file
variables
are initialized from their initial main thread values, i.e. the ones
without
the recapturing.
Unless I missed something ?
Michael.
On 25-11-2010 10:46, Anton Kavalenka wrote:
How to reinitialize RTL to have new threads started with working
output file (i.e. without need of rewrite).
regards,
Anton
In Delphi it works - with a critical section - without re-initialization
because it's var,
In FPC there's no easy
?? 25.11.2010 11:39, Thaddy ???(??):
On 25-11-2010 10:24, michael.vancann...@wisa.be wrote:
They are threadvars in trunk:
ThreadVar
ThreadID: TThreadID;
{ Standard In- and Output }
ErrOutput,
Output,
Input,
StdOut,
StdErr : Text;
Michael.
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as threadvar?
To prevent multiple threads writing to stdin/stdout/sterr at the same
time from corrupting each
On 25-11-2010 10:52, Anton Kavalenka wrote:
?? 25.11.2010 11:39, Thaddy ???(??):
Yes, How standard is standard? when you make it a threadvar.
Should I submit a bug report? It seems like I should:
Because the file drivers allow for redirection anyway and with good reason.
On 11/25/2010 10:24 AM, michael.vancann...@wisa.be wrote:
They are threadvars in trunk:
Of course if stdin, stdout, and stderr are not thredvars, their use is
not thread safe.
But if they are threadvars, how are they initialized ? Supposedly the
main thread instances are initialized as
On 25-11-2010 11:01, Jonas Maebe wrote:
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as threadvar?
To prevent multiple threads writing to stdin/stdout/sterr
?? 25.11.2010 12:01, Jonas Maebe ???(??):
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as threadvar?
To prevent multiple threads writing to
To quote some fiction: There can be only one.
In the context of stdxxx.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 25-11-2010 11:08, Michael Schnell wrote:
But what are the instances for threads connected to ?
This is - should be - opaque.
Regard,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
In our previous episode, Anton Kavalenka said:
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as threadvar?
To prevent multiple threads writing to
?? 25.11.2010 12:39, Marco van de Voort ???(??):
In our previous episode, Anton Kavalenka said:
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as
On 25 Nov 2010, at 11:16, Anton Kavalenka wrote:
?? 25.11.2010 12:01, Jonas Maebe ???(??):
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as threadvar?
On 25-11-2010 11:44, Jonas Maebe wrote:
On 25 Nov 2010, at 11:16, Anton Kavalenka wrote:
It's obviously better for Delphi compatibility and for what you want
to do, but in general I'd say that's simply a different way. It's also
worse in other ways: performance (not just locking/unlocking,
Am 25.11.2010 11:08, schrieb Michael Schnell:
On 11/25/2010 10:24 AM, michael.vancann...@wisa.be wrote:
They are threadvars in trunk:
Of course if stdin, stdout, and stderr are not thredvars, their use is
not thread safe.
But if they are threadvars, how are they initialized ? Supposedly the
?? 25.11.2010 13:14, Sven Barth ???(??):
Am 25.11.2010 11:08, schrieb Michael Schnell:
On 11/25/2010 10:24 AM, michael.vancann...@wisa.be wrote:
They are threadvars in trunk:
Of course if stdin, stdout, and stderr are not thredvars, their use is
not thread safe.
But if they are
On 11/25/2010 12:14 PM, Sven Barth wrote:
They are initialised when the thread is started (before your own
routine is called) to the same values that are used for StdIO on
application startup.
That means the StdIn, StdOut, and StdErr are opened multiple times by
the application ? While this
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
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
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
On 25-11-2010 20:15, Anton Kavalenka wrote:
At 25.11.2010 19:57, Jonas Maebe wrote:
On 25 Nov 2010, at 13:21, Jonas Maebe wrote:
the std streams should be on a per process basis (implementation as
var), not on a per thread basis (Iimplementation as threadvar).
Not only is this not Delphi
On 25-11-2010 18: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}
Dear All.
Currently to implement logger we use the following approach (the code
was implemented for Delphi/Kylix/FPC).
Logger is intended for displaying in the GUI outputs of several threads
and child processes and also for storage into internal bases.
Logic is the following:
Get stdout
On Wed, 24 Nov 2010, Anton Kavalenka wrote:
Dear All.
Currently to implement logger we use the following approach (the code was
implemented for Delphi/Kylix/FPC).
Logger is intended for displaying in the GUI outputs of several threads and
child processes and also for storage into internal
On 24-11-2010 21:32, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Anton Kavalenka wrote: Get stdout handle
(duplicate it under linux),
create pipe,
replace the stdout (keeping the old stdout) for current process with
write handle of pipe,
There are following problems with FPC
Under
40 matches
Mail list logo