Am 13.10.2010 00:51, schrieb Andrew Brunner:
This test case illustrates a FPC memory leak.
What makes you think so? Internally freed memory is not immediatly
released to the OS as well.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Am 12.10.2010 19:13, schrieb Marco van de Voort:
In our previous episode, David W Noon said:
ArchLinux does not use a System V init system, but a simpler BSD one.
And thus it does not use /etc/init.d, but only /etc/rc.d.
So does the BSD init use run levels?
Yes.
One of the major
Since the number of threads is set at compile time, I didn't expect to
see the much memory creep. The resource monitor for the process shows
about 15Mb of memory used. When the first group of 50 threads was
created and ran that climbed another 5 to about 20MB. Then every time
the system created
On Tue, Oct 12, 2010 at 5:51 PM, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
Another problem demonstrated with this application is the limiting
factor of thread creation. I'd like to make a complaint using this
code as well. Change the number of threads to 3000. The system gets
to about
On 13 Oct 2010, at 00:51, Andrew Brunner wrote:
The interesting thing I have noticed was that Arrays[n] of boolean can
be used without memory barriers. There is not one lock associated
with the boolean arrays and it always proves non-problematic on a 6
core system with 4gig ram. There are
On Wed, 13 Oct 2010, Andrew Brunner wrote:
On Tue, Oct 12, 2010 at 5:51 PM, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
Another problem demonstrated with this application is the limiting
factor of thread creation. I'd like to make a complaint using this
code as well. Change the number
On 13 Oct 2010, at 15:27, Jonas Maebe wrote:
1) on entry of the critical section protected by this variable,
you can have problems, because this sequence:
locked:=true;
local:=shared_global_var;
Of course, you normally need an atomic operation here to set locked
to true (otherwise
On Wed, Oct 13, 2010 at 8:27 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
1) on entry of the critical section protected by this variable, you can
have problems, because this sequence:
locked:=true;
local:=shared_global_var;
may actually be executed in this order:
On Wed, Oct 13, 2010 at 8:28 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
Probably because it uses a heap manager per thread.
You may try to use 'cmem', which will replace the heap manager with the C
memory manager (one for the whole app, not per thread). That will allow you
to test
On Wed, 13 Oct 2010, Andrew Brunner wrote:
On Wed, Oct 13, 2010 at 8:28 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
Probably because it uses a heap manager per thread.
You may try to use 'cmem', which will replace the heap manager with the C
memory manager (one for the whole app,
On Wed, Oct 13, 2010 at 2:12 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
FPC doesn't have anything to say about CPU allocation. The threads are
created by the C pthread library and Linux kernel.
They do the heavy work.
Is it possible I have the pthread library in some sort of debug
On Wed, 13 Oct 2010, Andrew Brunner wrote:
On Wed, Oct 13, 2010 at 2:12 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
FPC doesn't have anything to say about CPU allocation. The threads are
created by the C pthread library and Linux kernel.
They do the heavy work.
Is it possible I
On 09 Oct 2010, at 20:54, Jonas Maebe wrote:
On 09 Oct 2010, at 20:47, Bo Berglund wrote:
So it seems like the GMANE maintainers have either not understood or not
reconfigured this NG with the new setting.
I sent the request to GMANE only a few minutes before I posted the above to
the
I was reading on building FPC with debug enabled so I can trace into a
unit and found that it was way too difficult to find the parameters.
I know I had at one time edited the wiki page once I learned how to do
it but to my surprise that info was either lost/moved or too hard to
navigate and the
On Wed, Oct 13, 2010 at 3:24 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
Is it possible I have the pthread library in some sort of debug mode
that is slowing down the process of thread creation?
I seriously doubt it.
What you could do to test, is write your program using direct
15 matches
Mail list logo
