Op 2010-10-14 00:47, Jonas Maebe het geskryf:
>
> I've just received confirmation from the GMANE admin that they've made the
> gateway read-write now.
Awesome, thanks Jonas.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net:8
On Wed, Oct 13, 2010 at 3:24 PM, Michael Van Canneyt
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 Pthread calls.
> Th
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 se
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
On Wed, 13 Oct 2010, Andrew Brunner wrote:
On Wed, Oct 13, 2010 at 2:12 PM, Michael Van Canneyt
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 librar
On Wed, Oct 13, 2010 at 2:12 PM, Michael Van Canneyt
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 mode
that is slowing
On Wed, 13 Oct 2010, Andrew Brunner wrote:
On Wed, Oct 13, 2010 at 8:28 AM, Michael Van Canneyt
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 w
On Wed, Oct 13, 2010 at 8:28 AM, Michael Van Canneyt
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 this hypothesis.
On Wed, Oct 13, 2010 at 8:27 AM, 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;
>
> may actually be executed in this order:
>
> local:=shared_global_var;
> locked
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 mu
On Wed, 13 Oct 2010, Andrew Brunner wrote:
On Tue, Oct 12, 2010 at 5:51 PM, Andrew Brunner
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 s
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 boo
On Tue, Oct 12, 2010 at 5:51 PM, Andrew Brunner
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 1,000 and starts to "bog dow
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
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 distinctio
15 matches
Mail list logo
