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
ZeelandNet Webmail
Hi,
Today I was playing with FPDoc and I
decided to add creating the documents as a target to fpmake which seems
logical to me. I only did a very basic implementation to show tghe
principle so someone (Joost / Michael??) can shoot at it first before I
burn too much time
On Thu, 25 Nov 2010, dhkblas...@zeelandnet.nl wrote:
ZeelandNet Webmail
Hi,
Today I was playing with FPDoc and I
decided to add creating the documents as a target to fpmake which seems
logical to me. I only did a very basic implementation to show tghe
principle so someone (Joost /
I think it is a good and valuable idea. Do you have any plans to add
more functionality to it ?
I was thinking about adding a few more helper functions, such as adding
documentation for whole directories at a time. Also the documentation
output should be possible to be set, currently it's in
On Thu, 25 Nov 2010, dhkblas...@zeelandnet.nl wrote:
I think it is a good and valuable idea. Do you have any plans to add
more functionality to it ?
I was thinking about adding a few more helper functions, such as adding
documentation for whole directories at a time. Also the documentation
I think it is a good and valuable idea. Do you have any plans to
add
more functionality to it ?
I was thinking about adding a few more helper functions, such as
adding documentation for whole directories at a time. Also the
documentation output should be possible to be set, currently it's in
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}
36 matches
Mail list logo
