Guys, this is simply a semantic problem. I've got a six core system
here. The boolean array initialised all false. thdArray[0..9]
threads executing simultaneously. Corresponding values in
baArray[0..9]=false. baArray[n] = true iff thdArray[n] Terminated
(method assigned to each member of thdA
In our previous episode, Andrew Brunner said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Fri, Oct 8, 2010 at 3:37 PM, Marco van de Voort wrote:
> > No, but the last one might be set before the condition coupled to that last
> > one might be carried out. See Jonas' example.
>
> The ONL
On 08 Oct 2010, at 22:45, Andrew Brunner wrote:
> On Fri, Oct 8, 2010 at 3:37 PM, Marco van de Voort wrote:
>> No, but the last one might be set before the condition coupled to that last
>> one might be carried out. See Jonas' example.
>
> The ONLY way that could happen is if the boolean happen
On Fri, Oct 8, 2010 at 3:37 PM, Marco van de Voort wrote:
> No, but the last one might be set before the condition coupled to that last
> one might be carried out. See Jonas' example.
The ONLY way that could happen is if the boolean happens to be set in
a worker thread's method that still has mor
In our previous episode, Andrew Brunner said:
> Right. But in the case of an array of booleans that will be polled
> and an exit condition will only be met if all booleans are set to
> true. The order in which a polling thread sees them as being true has
> no bearing on the functionality.
No, bu
Right. But in the case of an array of booleans that will be polled
and an exit condition will only be met if all booleans are set to
true. The order in which a polling thread sees them as being true has
no bearing on the functionality.
On Fri, Oct 8, 2010 at 3:07 PM, Paulo Costa wrote:
> On 08
On 08/10/2010 18:35, Henry Vermaak wrote:
I think Jonas was talking about out of order execution in the cpu, not disk i/o.
No, it was out of order writing to memory (RAM), modern CPUs/Memory
controllers can do strange things reordering writes to RAM.
Paulo Costa
Hello FPC-Pascal,
Friday, October 8, 2010, 8:03:01 PM, you wrote:
SB> This isn't a race condition, but a dead lock (but both are bad things ^^).
You are right :) I'm used to use the "Deadlock" term when explicit
locks are being used, but yes, that's a DeadLock.
SB> Also on Windows this works, b
On 08.10.2010 18:27, Andrew Brunner wrote:
I'm needing help to take my Lazarus app, elevate process to root
(using GUI prompt like GKSU) and I want to drop back down to the
user's level after port binding and listening.
Ubuntu has port restrictions for low port numbers. I'm developing a
platfor
On 08.10.2010 18:13, José Mejuto wrote:
Hello FPC-Pascal,
Friday, October 8, 2010, 3:49:52 PM, you wrote:
GG> The application needs to wait for the logging threads to complete
GG> before it can terminate.
GG> This is where the problem comes in. As soon as I call
GG> SomeThread.WaitFor, the
On 8 October 2010 17:12, Andrew Brunner wrote:
> On Fri, Oct 8, 2010 at 9:52 AM, Jonas Maebe wrote:
>>> So are you referring to the topic of this conversation regarding data
>>> flushing? The notion of creating an index of completions to poll and
>>> waiting for all the values to turn true as a
I'm needing help to take my Lazarus app, elevate process to root
(using GUI prompt like GKSU) and I want to drop back down to the
user's level after port binding and listening.
Ubuntu has port restrictions for low port numbers. I'm developing a
platform that happens to use ports for HTTP, XMPP, e
On Fri, Oct 8, 2010 at 9:52 AM, Jonas Maebe wrote:
>> So are you referring to the topic of this conversation regarding data
>> flushing? The notion of creating an index of completions to poll and
>> waiting for all the values to turn true as a means to determine actual
>> job completion without u
Hello FPC-Pascal,
Friday, October 8, 2010, 3:49:52 PM, you wrote:
GG> The application needs to wait for the logging threads to complete
GG> before it can terminate.
GG> This is where the problem comes in. As soon as I call
GG> SomeThread.WaitFor, the application is frozen - it never gets to
GG> t
On 08 Oct 2010, at 16:33, Andrew Brunner wrote:
On Fri, Oct 8, 2010 at 9:21 AM, Jonas Maebe
wrote:
No, the main source of problems is that the cpu may reordering memory
operations resulting in those booleans in the arrays becoming true
before
all memory locations written in the thread are
On 8 October 2010 16:27, Sven Barth wrote:
> There is the problem: The main thread is waiting for the second thread to
> finish and the second thread is waiting for the main thread to find time to
> process its synchronized message. This is a classical DEADLOCK.
OK, with that clear explanation I n
On Fri, Oct 8, 2010 at 9:21 AM, Jonas Maebe wrote:
> No, the main source of problems is that the cpu may reordering memory
> operations resulting in those booleans in the arrays becoming true before
> all memory locations written in the thread are visible. The result is that
> you may try to use d
Am 08.10.2010 16:22, schrieb Michael Van Canneyt:
On Fri, 8 Oct 2010, Graeme Geldenhuys wrote:
On 8 October 2010 15:57, Andrew Brunner wrote:
A better way of achieving this is looking at the collection of threads
you have. Set your own booleans for Finished or if they
freeonterminate you wi
Am 08.10.2010 14:03, schrieb Graeme Geldenhuys:
if IsMultiThreaded then
begin
writeln('**');
CheckSynchronized();
end;
[snip]
procedure TBarThread.Execute;
begin
FFinished := False;// work-around variable
while not Terminated do
begin
On Fri, 8 Oct 2010, Graeme Geldenhuys wrote:
On 8 October 2010 15:57, Andrew Brunner wrote:
A better way of achieving this is looking at the collection of threads
you have. Set your own booleans for Finished or if they
freeonterminate you will need to create an
TCompletes=Array[0..threadcoun
On 08 Oct 2010, at 16:13, Andrew Brunner wrote:
I disagree. I've never had problems with setting values inside
boolean arrays in multi-threaded environments. The memory is already
allocated. Setting the value does not cause memory re-allocation,
which would be the only source of problems.
I disagree. I've never had problems with setting values inside
boolean arrays in multi-threaded environments. The memory is already
allocated. Setting the value does not cause memory re-allocation,
which would be the only source of problems. But of course just
because I didn't experience proble
On 8 October 2010 15:57, Andrew Brunner wrote:
> A better way of achieving this is looking at the collection of threads
> you have. Set your own booleans for Finished or if they
> freeonterminate you will need to create an
> TCompletes=Array[0..threadcount] of boolean. And as the threads free
> s
On 08 Oct 2010, at 15:57, Andrew Brunner wrote:
A better way of achieving this is looking at the collection of threads
you have. Set your own booleans for Finished or if they
freeonterminate you will need to create an
TCompletes=Array[0..threadcount] of boolean. And as the threads free
set th
A better way of achieving this is looking at the collection of threads
you have. Set your own booleans for Finished or if they
freeonterminate you will need to create an
TCompletes=Array[0..threadcount] of boolean. And as the threads free
set the variable of TCompletes to true. Then you can poll
On 8 October 2010 15:32, Andrew Brunner wrote:
> This seems like a discussion of semantics more than anything. In an
> application thread if you say WAITFOR something then the app cannot
> process messages b/c the execution is put on hold until WAITFOR
> returns. This is normal behaviour, IMO.
>
On 08 Oct 2010, at 15:26, Graeme Geldenhuys wrote:
On 8 October 2010 15:13, Jonas Maebe
wrote:
The timeout parameter is ignored when using cthreads, because the
pthreads
API does not support waiting for a thread termination with a timeout.
So what does Qt do different, so they have a
In our previous episode, Andrew Brunner said:
> This seems like a discussion of semantics more than anything. In an
> application thread if you say WAITFOR something then the app cannot
> process messages b/c the execution is put on hold until WAITFOR
> returns. This is normal behaviour, IMO.
>
This seems like a discussion of semantics more than anything. In an
application thread if you say WAITFOR something then the app cannot
process messages b/c the execution is put on hold until WAITFOR
returns. This is normal behaviour, IMO.
So if this is just an exercise, I really don't see a pro
On 8 October 2010 15:13, Jonas Maebe wrote:
>
> The timeout parameter is ignored when using cthreads, because the pthreads
> API does not support waiting for a thread termination with a timeout.
So what does Qt do different, so they have a wait option. From there
docs it doesn't explicitly ment
On 08 Oct 2010, at 15:13, Jonas Maebe wrote:
If you just want to quickly check whether the thread has finished,
check FThread.Finished (followed by FThread.Waitfor to clean it up
in case it's true).
I just noticed that's a private field that's not exposed. I guess the
only way is to inst
On 08 Oct 2010, at 14:52, Graeme Geldenhuys wrote:
I thought about the timeout, and dived into the WaitFor code. So I
changed my code from.
FThread.WaitFor;
..to...
WaitForThreadTerminate(FThread.Handle, 2000);
The timeout parameter is ignored when using cthreads, because the
pthr
On 8 October 2010 14:44, Andrew Brunner wrote:
>>
> What about dropping that loop and put it in UpdateProgressBar
>
> And drop the waitfor all together?
Ignore what the thread does... it's a dumb example. The thread can do
any long running job. I simply wanted to wait for it to finish before
I do
On 8 October 2010 14:40, Sven Barth wrote:
>
> 1. If you do a WaitFor the calling thread will be suspended until the thread
> you called WaitFor on terminates (or the timeout elapses, but our WaitFor
> doesn't have a timeout parameter...). Thus it is normal that your main loop
> appears to hang.
> procedure TBarThread.Execute;
> begin
> FFinished := False; // work-around variable
> while not Terminated do
> begin
> Synchronize(@UpdateProgressBar);
> end;
> FFinished := True; // work-around variable
> end;
>
What about dropping that loop and put it in UpdateProgressBar
TForm
Am 08.10.2010 14:11, schrieb Graeme Geldenhuys:
On 8 October 2010 13:32, Sven Barth wrote:
Let me guess: UID->username is a libc function...
Problem is you can't always map a UID to a username under Unix. The
username is not always in the /etc/passwd file. You can have LDAP (I
think that's w
Am 08.10.2010 13:43, schrieb Jonas Maebe:
On 08 Oct 2010, at 13:37, Sven Barth wrote:
Btw: the check for IsMultiThread inside of RTL code is a bit dangerous
as ported Delphi applications might set it manually to true out of old
habit (which is bad if the multithreading initialization checks th
Am 08.10.2010 14:03, schrieb Graeme Geldenhuys:
Hi,
On 8 October 2010 13:37, Sven Barth wrote:
Note: You must start at least one thread (besides the main thread) to turn
"IsMultiThread" to true.
I am, and changing my fpGUI code to the following does indeed prove
that you are right. As soon a
On 8 October 2010 13:32, Sven Barth wrote:
>
> Let me guess: UID->username is a libc function...
Problem is you can't always map a UID to a username under Unix. The
username is not always in the /etc/passwd file. You can have LDAP (I
think that's what it's called), Kerberos etc... users. I notic
Hi,
On 8 October 2010 13:37, Sven Barth wrote:
>
> Note: You must start at least one thread (besides the main thread) to turn
> "IsMultiThread" to true.
I am, and changing my fpGUI code to the following does indeed prove
that you are right. As soon as my thread is started, I see the '*'
outpu
On 08 Oct 2010, at 13:32, Sven Barth wrote:
Let me guess: UID->username is a libc function...
It has to be implemented via a library, because the translation can be
done in as many different ways as there are authentication systems (/
etc/passwd, NIS, kerberos, ActiveDirectory, ...).
Jo
On 08 Oct 2010, at 13:37, Sven Barth wrote:
Btw: the check for IsMultiThread inside of RTL code is a bit
dangerous as ported Delphi applications might set it manually to
true out of old habit (which is bad if the multithreading
initialization checks that var).
Such applications are simpl
On 08 Oct 2010, at 13:33, Graeme Geldenhuys wrote:
Is it the line with InterlockedExchange() call?
Yes.
The reason I ask, I'm
using FPC 2.4.3 under 64-bit linux and using fpGUI. All other
platforms has a clear 'IsMultiThreaded := True' in the RTL code,
Multiple threads may be started simu
Am 08.10.2010 13:33, schrieb Graeme Geldenhuys:
Hi,
Is it the line with InterlockedExchange() call? The reason I ask, I'm
using FPC 2.4.3 under 64-bit linux and using fpGUI. All other
platforms has a clear 'IsMultiThreaded := True' in the RTL code, but
not for Unix. It seems CheckSynchronized()
Hi,
Is it the line with InterlockedExchange() call? The reason I ask, I'm
using FPC 2.4.3 under 64-bit linux and using fpGUI. All other
platforms has a clear 'IsMultiThreaded := True' in the RTL code, but
not for Unix. It seems CheckSynchronized() is never called in
fpGUI/X11 because IsMultiThrea
Am 08.10.2010 11:43, schrieb Michael Van Canneyt:
On Fri, 8 Oct 2010, Sven Barth wrote:
Am 08.10.2010 10:03, schrieb Michael Van Canneyt:
So when changing/improving GetTempFileName we could also try to make
it compatible to such applications by creating a directory in TEMP for
the temporary
On Fri, 8 Oct 2010, Sven Barth wrote:
Am 08.10.2010 10:03, schrieb Michael Van Canneyt:
On Fri, 8 Oct 2010, Sven Barth wrote:
Am 07.10.2010 20:02, schrieb Jonathan:
On Thu, 07 Oct 2010 11:01:44 +0200
Sven Barth wrote:
Btw: What are Tomoyo and Apparmour (I can imagine what the second on
Am 08.10.2010 10:03, schrieb Michael Van Canneyt:
On Fri, 8 Oct 2010, Sven Barth wrote:
Am 07.10.2010 20:02, schrieb Jonathan:
On Thu, 07 Oct 2010 11:01:44 +0200
Sven Barth wrote:
Btw: What are Tomoyo and Apparmour (I can imagine what the second one
is, but I don't know what functionality
Thanks for fast and helpful answer. It works fine.
TRoland;
<<< 08.10.2010 10:41 - Jonas Maebe "jonas.ma...@elis.ugent.be" >>>
JM> On 08 Oct 2010, at 10:33, Roland Turcan wrote:
>> I have this conversion:
>>
>> type TWordSet = set of 0..15;
>> PWordSet = ^TWordSet;
>>
>> var btn: TMsgDlgBu
On 08 Oct 2010, at 10:33, Roland Turcan wrote:
I have this conversion:
type TWordSet = set of 0..15;
PWordSet = ^TWordSet;
var btn: TMsgDlgButtons;
begin
...
Integer(PWordSet(@btn)^) := Params[0]; // Params is Variant
...
end;
With FPC 2.4 it is OK, but up-to-date FPC SVN reports e
>>
>> I didn't try it, but I see that it tries to connect to google's dns serve=
>r,
>> so it'd fail miserably if the computer has no internet access.
>>
>> Bye
>> --
>> Luca
>>
>
>I tested, without web access does not work. :o
A hard coded address will of course fail if it cannot be reached.
The c
Hello FPC-Pascal users discussions!
I have this conversion:
type TWordSet = set of 0..15;
PWordSet = ^TWordSet;
var btn: TMsgDlgButtons;
begin
...
Integer(PWordSet(@btn)^) := Params[0]; // Params is Variant
...
end;
With FPC 2.4 it is OK, but up-to-date FPC SVN reports error in
su
On Fri, 8 Oct 2010, Sven Barth wrote:
Am 07.10.2010 20:02, schrieb Jonathan:
On Thu, 07 Oct 2010 11:01:44 +0200
Sven Barth wrote:
Btw: What are Tomoyo and Apparmour (I can imagine what the second one
is, but I don't know what functionality they provide)?
http://tomoyo.sourceforge.jp/
htt
Am 07.10.2010 20:02, schrieb Jonathan:
On Thu, 07 Oct 2010 11:01:44 +0200
Sven Barth wrote:
Btw: What are Tomoyo and Apparmour (I can imagine what the second one
is, but I don't know what functionality they provide)?
http://tomoyo.sourceforge.jp/
https://wiki.ubuntu.com/AppArmor
Thanks.
S
54 matches
Mail list logo
