Hi Folks.
I'm facing a problem where threads are involved.
I have a test program with a main form and using threads. When I run
without threads, a Close button executed the TForm.Close method and the
program terminates without problem.
But when the threads (one or more) on closing, the
Sorry, I did forget some information:
Win32: Lazarus 1.0.10
Linux: x86_64, Lazarus 1.0.8
The threads are defined in the main form.
When the threads are used, the program does not hang, the main form
gains control but the program does not terminate.
Antonio.
--
FTimeOut needs to be (a lot) lower than MAX_DELAY.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Le 27/08/2013 11:22, Michael Schnell a écrit :
FTimeOut needs to be (a lot) lower than MAX_DELAY.
Timeout runs from 100 to about 400 ms whereas MAX_DELAY. is fixed to 600 ms
You should note that all threads send the last message to the Q which
means that the Terminate has been trapped.
On 23/03/2012 16:10, Michael Schnell wrote:
BTW.: Do you know this ?
www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
-Michael O:-)
Cool especially the last sentence...
Threads must be relegated to the engine room of computing, to be suffered only
by expert technology providers
Lukasz Sokol wrote:
On 23/03/2012 16:10, Michael Schnell wrote:
BTW.: Do you know this ?
www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
-Michael O:-)
Cool especially the last sentence...
Threads must be relegated to the engine room of computing, to be suffered only
by expert
On 26/03/2012 12:24, Mark Morgan Lloyd wrote:
Cool especially the last sentence... Threads must be relegated to
the engine room of computing, to be suffered only by expert
technology providers
Equally significant, in my view, is the second sentence:
Languages require little or no
Le 22/03/2012 16:20, Mattias Gaertner a écrit :
Each thread has its own stack.
All threads share the same address space and the same heap.
Objects (here: class instances) are created on the heap. The heap is
thread safe.
The data segment is for constants. They are shared.
Le 22/03/2012
Am 23.03.2012 10:25, schrieb Antonio Fortuny:
Le 22/03/2012 16:20, Mattias Gaertner a écrit :
Each thread has its own stack.
All threads share the same address space and the same heap.
Objects (here: class instances) are created on the heap. The heap is
thread safe.
The data segment is for
Antonio Fortuny schrieb:
Trying to be as much clear as possible, there are some sentences:
Assuming this few statements (aka my own rules when writing thread's code):
a. all thread code+data are encapsulated into a TThread object
b. Thread safe means that there is no overlap of data references
Thanks Sven, I really appreciate.
Le 23/03/2012 10:59, Sven Barth a écrit :
Am 23.03.2012 10:25, schrieb Antonio Fortuny:
Le 22/03/2012 16:20, Mattias Gaertner a écrit :
Each thread has its own stack.
All threads share the same address space and the same heap.
Objects (here: class
Many thanks Dodi.
Antonio.
Le 23/03/2012 10:59, Hans-Peter Diettrich a écrit :
Antonio Fortuny schrieb:
Trying to be as much clear as possible, there are some sentences:
Assuming this few statements (aka my own rules when writing thread's
code):
a. all thread code+data are encapsulated
It's rather straight forward to do completely distinct threads.
The tricky part starts, when the threads need to communicate (which
always is necessary) and thus share some data.
Here you need to be aware of several things:
- the components and functions in the LCL and RTL usually are not
Le 23/03/2012 15:24, Michael Schnell a écrit :
It's rather straight forward to do completely distinct threads.
The tricky part starts, when the threads need to communicate (which
always is necessary) and thus share some data.
Here you need to be aware of several things:
- the components
Am 23.03.2012 15:36, schrieb Antonio Fortuny:
Le 23/03/2012 15:24, Michael Schnell a écrit :
It's rather straight forward to do completely distinct threads.
The tricky part starts, when the threads need to communicate (which
always is necessary) and thus share some data.
Here you need to be
All those are the basics that I apply since I'm busy writing threads
code. I already make use of Critical sections and events lock some
external resources (log files for instance) and I avoid to have any
thread code using any kind of GUI. All thread code I write, is contained
in OS services or
On 03/23/2012 03:36 PM, Antonio Fortuny wrote:
All thread code I write, is contained in OS services or very
specialized programs having no GUI at all.
Here this issue might be a problem (it was for me):
- The functionality of TThread.Synchronize and
Application.QueuAsyncCall is not available
BTW.: Do you know this ?
www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
-Michael O:-)
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Antonio Fortuny schrieb:
5. all useful code a thread needs should be encapsultated into a
TObject descendant and instantiated within the thread's space.
This can all be implemented in the derived TThread class.
So, building an object around this utility code does not enlarge thread
safety ?
Hi folks.
Wen launching a thread, the process responsible for the thread object
creation and the call to TThread.Start and the thread EXECUTE procedure,
run in parallel. That's why the SYNCHRONIZE procedure exists and that
the developer has to pay attention to not share code between threads.
Antonio Fortuny a.fort...@sitasoftware.lu hat am 22. März 2012 um 15:32
geschrieben:
Hi folks.
Wen launching a thread, the process responsible for the thread object
creation and the call to TThread.Start and the thread EXECUTE procedure,
run in parallel. That's why the SYNCHRONIZE procedure
Besides what the other said a very basic comment.
The location where an object is defined (i.e. within a TThread enabled
unit) or who created it (the main line code or the thread code) does not
matter. The Concept of classes, objects and instances is a matter of
memory allocation and pointers
Hi all.
Is it any chance that a running thread derived from TTHREAD ignores the
FreeOnTerminate flag ?
Antonio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On Thu, 08 Mar 2012 15:50:32 +0100
Antonio Fortuny a.fort...@sitasoftware.lu wrote:
Hi all.
Is it any chance that a running thread derived from TTHREAD ignores the
FreeOnTerminate flag ?
FreeOnTerminate works here.
Maybe your thread has an uncaught exception?
Mattias
--
On 09/17/2010 05:49 PM, Mattias Gaertner wrote:
Note: afaik CILK is the same as parallel loops: It allows to make some
special cases need less typing, can increase readability and can
decrease overhead.
Of course parallel loops is just less typing than doing the same
functionality in user
On 09/18/2010 06:08 PM, Dariusz Mazur wrote:
with CILK approach we deal with task, not threads.
IMHO this does not make much sense.
For the user-programmer, the relevant difference between tasks and
threads is that thread share memory.
This results in the increasing complexity with
On 09/20/2010 01:55 PM, Mattias Gärtner wrote:
for i:=1 to 1 do
spawn DoSomething(i);
Who has a 1 Core hardware ?
But with some Super-Computers, spawning some thousand DoSomethings might
be viable.
Usually any type of parallel implementation in a language or a library
On 09/19/2010 11:45 AM, Graeme Geldenhuys wrote:
If you understand the possible problems, it is rather a question of:
Why did they take so long to deprecate the flaw. Imagine your
thread has locked a major resource, now you suspend that thread. A
instant deadlock occurs because that thread
W dniu 2010-09-20 09:25, Mattias Gaertner pisze:
On Sun, 19 Sep 2010 22:22:21 +0200
Dariusz Mazurdar...@emadar.com wrote:
W dniu 2010-09-18 18:55, Mattias Gaertner pisze:
[...]
Whats about CILK http://en.wikipedia.org/wiki/Cilk
|_function_ fib (n: integer):integer;
var
x,y :
Zitat von Dariusz Mazur dar...@emadar.com:
[...]
Before using multi threading, try to use a better single threaded
algorithm. And when comparing multi with single threading speed, you
must not compare a multi threaded algorithm running single threaded, but
a multi threaded algorithm with a
W dniu 2010-09-20 13:55, Mattias Gärtner pisze:
Zitat von Dariusz Mazur dar...@emadar.com:
[...]
Before using multi threading, try to use a better single threaded
algorithm. And when comparing multi with single threading speed, you
must not compare a multi threaded algorithm running single
Zitat von Dariusz Mazur dar...@emadar.com:
[...]
Most of programs are huge count of simple computing. There are many
places, that things may run parallel without pain. But very often
this places are computing short, thus very often overhead of
starting thread is bigger than using second
I like the current TThread =)
I am writing a strategy game and I noticed how much time it takes to
load the map, so why make the user wait? I simply put the map loading
in a thread and while the map loads the user can use the user
interface to choose a scenario or configure the game. If he is
W dniu 2010-09-20 16:09, Sven Barth pisze:
Am 20.09.2010 15:22, schrieb Dariusz Mazur:
W dniu 2010-09-20 13:55, Mattias Gärtner pisze:
Zitat von Dariusz Mazur dar...@emadar.com:
[...]
Before using multi threading, try to use a better single threaded
algorithm. And when comparing multi with
W dniu 2010-09-20 16:03, Mattias Gärtner pisze:
Zitat von Dariusz Mazur dar...@emadar.com:
[...]
Most of programs are huge count of simple computing. There are many
places, that things may run parallel without pain. But very often
this places are computing short, thus very often overhead of
On Mon, 20 Sep 2010 20:45:04 +0200
Dariusz Mazur dar...@emadar.com wrote:
[...]
Start a wiki page with a proposal for the syntax.
Create a unit like mtprocs that demonstrates CILK and how the syntax
should be converted by the compiler.
Find someone to implement and, more important,
On 19.09.2010 00:17, Marco van de Voort wrote:
On Wed, Sep 15, 2010 at 10:48:09AM +0200, Michael Van Canneyt wrote:
I was amazed that there isn't a single use of threads in Lazarus code base.
Threads however are the thing of the future because computers have more and
more CPU cores. Threads
On 19 September 2010 11:12, Sven Barth pascaldra...@googlemail.com wrote:
Well, one pain less. Delphi deprecated suspending/resuming of threads.
Huh? O.o Did they give a reason for this move?
Quoting from a Linux website (but applies to windows and other platforms too)
Notice that
On 19 September 2010 01:33, Andrew Brunner wrote:
On Sat, Sep 18, 2010 at 5:17 PM, Marco van de Voort wrote:
Well, one pain less. Delphi deprecated suspending/resuming of threads.
Sometimes you have to ask what where they thinking?
If you understand the possible problems, it is rather a
On Sat, Sep 18, 2010 at 06:33:19PM -0500, Andrew Brunner wrote:
On Sat, Sep 18, 2010 at 5:17 PM, Marco van de Voort mar...@stack.nl wrote:
Well, one pain less. Delphi deprecated suspending/resuming of threads.
That makes for interesting news. What about suspending / resuming
Manager
On 19.09.2010 11:40, Graeme Geldenhuys wrote:
On 19 September 2010 11:12, Sven Barthpascaldra...@googlemail.com wrote:
Well, one pain less. Delphi deprecated suspending/resuming of threads.
Huh? O.o Did they give a reason for this move?
Quoting from a Linux website (but applies to windows
W dniu 2010-09-18 18:55, Mattias Gaertner pisze:
On Sat, 18 Sep 2010 18:08:09 +0200
Dariusz Mazurdar...@emadar.com wrote:
W dniu 2010-09-17 17:49, Mattias Gaertner pisze:
On Fri, 17 Sep 2010 14:09:59 +0200
Dariusz Mazurdar...@emadar.com wrote:
[...]
Whats about CILK
W dniu 2010-09-17 17:49, Mattias Gaertner pisze:
On Fri, 17 Sep 2010 14:09:59 +0200
Dariusz Mazurdar...@emadar.com wrote:
[...]
Whats about CILK http://en.wikipedia.org/wiki/Cilk
|_function_ fib (n: integer):integer;
var
x,y : integer;
begin
if (n 2) then exit(n)
On Sat, 18 Sep 2010 18:08:09 +0200
Dariusz Mazur dar...@emadar.com wrote:
W dniu 2010-09-17 17:49, Mattias Gaertner pisze:
On Fri, 17 Sep 2010 14:09:59 +0200
Dariusz Mazurdar...@emadar.com wrote:
[...]
Whats about CILK http://en.wikipedia.org/wiki/Cilk
|_function_ fib (n:
On Wed, Sep 15, 2010 at 10:48:09AM +0200, Michael Van Canneyt wrote:
I was amazed that there isn't a single use of threads in Lazarus code base.
Threads however are the thing of the future because computers have more and
more CPU cores. Threads are a way to utilize them.
Threads are a
On Sat, Sep 18, 2010 at 5:17 PM, Marco van de Voort mar...@stack.nl wrote:
Well, one pain less. Delphi deprecated suspending/resuming of threads.
That makes for interesting news. What about suspending / resuming
Manager Systems that use threads for service applications...
Sometimes you have to
Ok, I used Application.AddOnIdleHandler for the task instead of a thread.
First I tried TIdleTimer first but it is confusing.
Sometimes OnStartTimer handler was called first, sometimes OnTimer.
What does Interval do when the context is idle time?
What about AutoEnabled versus Enabled?
Now the
On Fri, 17 Sep 2010, Juha Manninen (gmail) wrote:
I honestly wonder the attitude against threads here. I hear comments of Pascal
being a dying language from the past. Maybe it is true after all.
How can one take seriously a developer community which claims threading is
inherently wrong and
Am 17.09.2010 10:29, schrieb Juha Manninen (gmail):
BTW, TThread class has a good and intuitive interface, IMO. A new language
syntax for parallelism would be nice but it wouldn't make any fundamental
difference. Start a thread and call WaitFor later. How much easier can it be?
Same can be
On Fri, 17 Sep 2010, Graeme Geldenhuys wrote:
On 17 September 2010 10:43, Michael Van Canneyt wrote:
But the possible side effects were pointed out, and the consequences that
usage of threads has IN THE IDE. And the opinion was raised that if there is
a way to accomplishing the same task
Am 17.09.2010 11:00, schrieb Graeme Geldenhuys:
On 17 September 2010 10:47, Florian Klaempfl wrote:
Same can be said about goto and labels. Very intuitive and simple why
bother about while, for, repeat loops?
Please keep such sarcasm
This is your personal opinion. I don't consider it as
On 17 September 2010 11:11, Florian Klaempfl wrote:
This is your personal opinion. I don't consider it as sarcasm but as
truth. The current models of threading are imo simple flawed and need
major improvements, maybe even a new programming paradigmas to be usable
in programs in a robust and
On Friday 17 September 2010 11:47:12 Florian Klaempfl wrote:
Same can be said about goto and labels. Very intuitive and simple why
bother about while, for, repeat loops?
Well, it is a valid comparison. I remember reading about new syntax in some
languages. One is a future variable which you
On 09/17/2010 10:43 AM, Michael Van Canneyt wrote:
Threads are one way of implementing parallel computing.
What other decent way is there to allow parallel computing (I here mean
using multiple CPUs) in a single program running on an SMP OS ?
-Michael
--
On Fri, 17 Sep 2010, Juha Manninen (gmail) wrote:
On Friday 17 September 2010 11:43:24 Michael Van Canneyt wrote:
I understand that it may be harder and less easy for your particular task.
Maybe you can submit your work so the IDE experts can offer better and more
responsive ways of doing
On Fri, 17 Sep 2010, Michael Schnell wrote:
On 09/17/2010 10:43 AM, Michael Van Canneyt wrote:
Threads are one way of implementing parallel computing.
What other decent way is there to allow parallel computing (I here mean using
multiple CPUs) in a single program running on an SMP OS ?
On 09/17/2010 11:48 AM, Juha Manninen (gmail) wrote:
On Friday 17 September 2010 11:47:12 Florian Klaempfl wrote:
Same can be said about goto and labels. Very intuitive and simple why
bother about while, for, repeat loops?
Well, it is a valid comparison. I remember reading about new syntax in
Am 17.09.2010 13:33, schrieb Michael Schnell:
On 09/17/2010 11:48 AM, Juha Manninen (gmail) wrote:
On Friday 17 September 2010 11:47:12 Florian Klaempfl wrote:
Same can be said about goto and labels. Very intuitive and simple why
bother about while, for, repeat loops?
Well, it is a valid
The parallel loop solves nothing which makes threading hard and is only
a cheap excuse. The real problems of threading are synchronization and
especially abording threads e.g. triggered by the main thread.
Whats about CILK http://en.wikipedia.org/wiki/Cilk
|_function_ fib (n:
Zitat von Vincent Snijders vincent.snijd...@gmail.com:
2010/9/17 Juha Manninen (gmail) juha.mannine...@gmail.com:
I committed it in r.27384.
Now I call AddOnIdleHandler before creating the form. I also tried passing
variables through form constructor and calling AddOnIdleHandler from
I've been following this thread for a while and there has been much
talk about the obvious trials but I have yet to read anything
regarding the justification for the added overhead or the acceptance
of parallelization (for perhaps some text searching)?
There is definitely great interest in making
Am 15.09.2010 18:33, schrieb David W Noon:
This now brings us to the idea of building a debugger more suitable to
FPC, Lazarus and the Pascal language generally.
You are not the first one to have this idea:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/debugger/fpdebug/?root=lazarus
2010/9/15 David W Noon :
I think Graeme's point is that FPC's linkage to GDB is made up largely
of chewing gum and string as it is, so adding multi-threading does not
make any significant increase in the difficulty.
You understood me correctly.
This now brings us to the idea of building a
On 15 September 2010 23:12, waldo kitty wrote:
the first think i'd probably end up doing is giving that sucker a much
shorter name! :lol:
:-) That name comes from being delphi compatible. Good old Borland
came up with that mouth full.
--
Regards,
- Graeme -
On 09/15/2010 05:25 PM, Michael Schnell wrote:
That is why I vote for a message queue for the threads (implemented in
the RTL).
Just for the record:
I once tested (using Delphi) creating another TApplication instance in a
TThread and without any problems I got a thread that not only does
Hi
I thought first to send this to Lazarus dev list but it may have wider interest
so I send it here.
I am going to commit a patch for converter (=part of Lazarus code base) that
uses TThread. It caches some unit paths in backround so that the converter
settings dialog appears without delay.
On Wed, 15 Sep 2010, Juha Manninen (gmail) wrote:
I was amazed that there isn't a single use of threads in Lazarus code base.
Threads however are the thing of the future because computers have more and
more CPU cores. Threads are a way to utilize them.
Threads are a thing of the past as
On Wednesday 15 September 2010 11:48:09 Michael Van Canneyt wrote:
Threads are a thing of the past as well. I've been programming threads
since years. There is nothing exciting about them, mostly they are a pain.
Correct but now there is no better way to implement parallelism. I know some
On Wed, 15 Sep 2010, Juha Manninen (gmail) wrote:
On Wednesday 15 September 2010 11:48:09 Michael Van Canneyt wrote:
Threads are a thing of the past as well. I've been programming threads
since years. There is nothing exciting about them, mostly they are a pain.
Correct but now there is no
Michael Van Canneyt wrote:
On Wed, 15 Sep 2010, Juha Manninen (gmail) wrote:
On Wednesday 15 September 2010 11:48:09 Michael Van Canneyt wrote:
Threads are a thing of the past as well. I've been programming threads
since years. There is nothing exciting about them, mostly they are a
pain.
On Wednesday 15 September 2010 12:28:55 Marc Weustink wrote:
In case of lazarus, what do you want to do in a thread ?
I actually explained it in the original mail.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
2010/9/15 Juha Manninen (gmail) juha.mannine...@gmail.com:
Question: why is there need for UseCThreads define. Isn't cthreads needed
always when using a *nix system? So, can I change the definition to :
{$IFDEF UNIX}
cthreads,
{$ENDIF}
If I now commit my code as it is, there will be
2010/9/15 Juha Manninen (gmail) juha.mannine...@gmail.com:
What would you suggest? How to commit the code so that we don't get complaints
about RunErrors?
I suggest:
Don't use threads, but take a look at the code browser, how to quickly
show a dialog, while information is still being gathered.
On 09/15/2010 10:48 AM, Michael Van Canneyt wrote:
Threads are a thing of the past as well. I've been programming threads
since years.
There is nothing exciting about them, mostly they are a pain.
OK, but
how do you make a program that is able to non sluggishly communicate
with the user
On 09/15/2010 11:17 AM, Michael Van Canneyt wrote:
Well...
IMHO the whole threading model is basically flawed, but currently
there is no other alternative. At least not in any language I know.
Delphi Prism does know parallel loops and several related constructs.
Here the .NET or Mono
Maybe you could start an external process for this
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
... how to avoid performance and latency killing polling while wait
for multiple events such as needed in TCP servers handling many clients
at the time or embedded applications handling multiple serial and
other machine interfaces ?
-Michael
--
On Wednesday 15 September 2010 13:32:20 Michael Schnell wrote:
Maybe you could start an external process for this
... and pass the data with temporary text files?
Why would I do that? A thread is lighter, it can see the variables I already
defined, it is easier to synchronize (WaitFor in
On Wed, 15 Sep 2010, Michael Schnell wrote:
On 09/15/2010 10:48 AM, Michael Van Canneyt wrote:
Threads are a thing of the past as well. I've been programming threads
since years.
There is nothing exciting about them, mostly they are a pain.
OK, but
how do you make a program that is able
On 09/15/2010 12:38 PM, Juha Manninen (gmail) wrote:
On Wednesday 15 September 2010 13:32:20 Michael Schnell wrote:
Maybe you could start an external process for this
... and pass the data with temporary text files?
Why would I do that? A thread is lighter, it can see the variables I
On Wednesday 15 September 2010 12:42:58 Vincent Snijders wrote:
By default Lazarus is a single threaded application. Only if a lazarus
packages that uses threads is used, the IDE needs to include the
cthreads unit. Such packages add -dUseCThreads in their usage options
(Open package, Options -
On 15 September 2010 12:38, Juha Manninen (gmail) wrote:
On Wednesday 15 September 2010 13:32:20 Michael Schnell wrote:
Maybe you could start an external process for this
... and pass the data with temporary text files?
Why would I do that? A thread is lighter, it can see the variables
On 09/15/2010 01:00 PM, Juha Manninen (gmail) wrote:
Ok, I will check the OnIde handler solution
Hmm,
I suppose the GUI will not react while the task you run in OnIdle is
busy. So you will need to split your add-on in tiny pieces and run one
after the other in subsequent OnIdle callbacks.
On Wednesday 15 September 2010 13:46:07 Michael Schnell wrote:
Linux is very good with passing data via pipes. stdout is always present
and can be captured by the parent process. This in fact is the Unix
way to do those things (rather than using Threads). But I am sure it
can be done with
On 15 September 2010 13:07, Michael Schnell wrote:
I suppose the GUI will not react while the task you run in OnIdle is
busy. So you will need to split your add-on in tiny pieces and run one after
the other in subsequent OnIdle callbacks.
Or use a thread and make the code simpler! :)
--
On 15 September 2010 13:07, Juha Manninen (gmail) Nothing. It's
just error-prone. Enabling CThreads slightly reduces the
overall performance, but I don't think it's relevant.
Ok, so there is a technical reason against threads, a performance hit.
I didn't know.
I would like to see performance
On 09/15/2010 01:07 PM, Juha Manninen (gmail) wrote:
Anyway, it doesn't sound very easy for a crossplatform solution.
Only because a (well accepted) platform-independent infrastructure is
lacking. FPC does come with a lot of platform independent stuff like
TThread, TEvent, TCriticalSection
2010/9/15 Graeme Geldenhuys graemeg.li...@gmail.com:
On 15 September 2010 13:00, Juha Manninen (gmail)
The main trend in programming now is to encourage threading, not to ban it.
I am little puzzled...
+1
As I said, threading is an advanced feature, and clearly here are
many developers
On Wed, 15 Sep 2010 13:05:40 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 15 September 2010 12:38, Juha Manninen (gmail) wrote:
On Wednesday 15 September 2010 13:32:20 Michael Schnell wrote:
Maybe you could start an external process for this
... and pass the data with
On Wed, 15 Sep 2010, Juha Manninen (gmail) wrote:
On Wednesday 15 September 2010 13:32:20 Michael Schnell wrote:
Maybe you could start an external process for this
... and pass the data with temporary text files?
Why would I do that? A thread is lighter, it can see the variables I
On 15 September 2010 12:09, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 15 September 2010 13:07, Michael Schnell wrote:
I suppose the GUI will not react while the task you run in OnIdle is
busy. So you will need to split your add-on in tiny pieces and run one after
the other in
On Wed, 15 Sep 2010 11:45:41 +0200
Vincent Snijders vincent.snijd...@gmail.com wrote:
2010/9/15 Juha Manninen (gmail) juha.mannine...@gmail.com:
What would you suggest? How to commit the code so that we don't get
complaints
about RunErrors?
I suggest:
Don't use threads, but take a
Juha Manninen (gmail) wrote:
so I rebuilt Lazarus with -dUseCThreads. Now it works perfectly!
Question: why is there need for UseCThreads define. Isn't cthreads needed
always when using a *nix system?
Threads have been stable on x86 Linux for a few years, but rather less
so on some other
On Wed, 15 Sep 2010 12:46:10 +0200 (CEST)
Michael Van Canneyt mich...@freepascal.org wrote:
On Wed, 15 Sep 2010, Michael Schnell wrote:
On 09/15/2010 10:48 AM, Michael Van Canneyt wrote:
Threads are a thing of the past as well. I've been programming threads
since years.
There
On Wed, 15 Sep 2010 14:00:19 +0300
Juha Manninen (gmail) juha.mannine...@gmail.com wrote:
On Wednesday 15 September 2010 12:42:58 Vincent Snijders wrote:
By default Lazarus is a single threaded application. Only if a lazarus
packages that uses threads is used, the IDE needs to include the
On Wed, 15 Sep 2010 13:07:38 +0200
Michael Schnell mschn...@lumino.de wrote:
On 09/15/2010 01:00 PM, Juha Manninen (gmail) wrote:
Ok, I will check the OnIde handler solution
Hmm,
I suppose the GUI will not react while the task you run in OnIdle is
busy. So you will need to split your
On Wed, 15 Sep 2010 12:30:29 +0100
Henry Vermaak henry.verm...@gmail.com wrote:
On 15 September 2010 12:09, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 15 September 2010 13:07, Michael Schnell wrote:
I suppose the GUI will not react while the task you run in OnIdle is
busy. So
On 09/15/2010 12:46 PM, Michael Van Canneyt wrote:
What is so performance killing about process messages ?
process message is a function call that obviously take some microseconds
to run. Thus, if you do it very often, it degrades the overall
performance, if you do it rather seldom, the
On 09/15/2010 12:35 PM, Juha Manninen (gmail) wrote:
+1
I would love that!
:) (This already has been discussed here some months ago.)
I feel that this non-trivial performance-targeting project should not be
started before (as discussed recently) the libc binding of the TThread
On Wed, Sep 15, 2010 at 13:56, Michael Schnell mschn...@lumino.de wrote:
On 09/15/2010 12:46 PM, Michael Van Canneyt wrote:
What is so performance killing about process messages ?
process message is a function call that obviously take some microseconds to
run. Thus, if you do it very
101 - 200 of 214 matches
Mail list logo
