Hello.
You may use RTLEvents to pause a thread. =>
Program Project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Classes;
Type
{ THelloThread }
THelloThread = class(TThread)
fSleepTime,fThreadNum:integer;
fEvent:PRTLEvent;
procedure Execute; override;
synchronising tools do not do what you want?
De: fpc-pascal-boun...@lists.freepascal.org
em nome de Xiangrong Fang
Enviado: quarta-feira, 25 de fevereiro de 2015 12:33
Para: FPC-Pascal users discussions
Assunto: Re: [fpc-pascal] Use sleep in thread
2015-02-25
2015-02-25 23:16 GMT+08:00 :
> not sure if this helps, but:
> for example, if you want thread T to run using approx. 70% of max.
> available capacity, try this:
>
> repeat
> T.Resume;
> Sleep(70);
> T.Resume;
> Sleep(30);
> until ...
>
This seems not what I want. I would like to schedule
On Wed, Feb 25, 2015 at 06:17:17PM +0300, hinsta...@yandex.ru wrote:
> I mean T.Suspend, so u resume it then suspend it
TThread.Suspend and TThread.Resume are deprecated (since 2.4.4), don't
use them.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.
On 02/25/2015 03:41 PM, Xiangrong Fang wrote:
Can I use Sleep() in a thread to give up cpu time to other threads
running at the same time
AFAIK:
Sleep(n) makes the thread give up CPU for _at_least_ n milliseconds
Sleep(0) makes it give up it's current time slice and is due to be
re-schedule
On Wed, Feb 25, 2015 at 10:41:58PM +0800, Xiangrong Fang wrote:
> Hi All,
>
> Can I use Sleep() in a thread to give up cpu time to other threads running
> at the same time, so as to adjust the relative "niceness" of a group of
> workers working on the same subject (in which each thread take part o
I mean T.Suspend, so u resume it then suspend it
25.02.2015, 18:16, "hinsta...@yandex.ru" :
> not sure if this helps, but:
> for example, if you want thread T to run using approx. 70% of max. available
> capacity, try this:
>
> repeat
> T.Resume;
> Sleep(70);
> T.Resume;
> Sleep(30);
> u
not sure if this helps, but:
for example, if you want thread T to run using approx. 70% of max. available
capacity, try this:
repeat
T.Resume;
Sleep(70);
T.Resume;
Sleep(30);
until ...
so T runs for 70 ms, then sleeps for 30 ms, etc
25.02.2015, 18:06, "Xiangrong Fang" :
> 2015-02-25 22:
2015-02-25 22:47 GMT+08:00 Dmitry Boyarintsev :
> I presume most of the systems would make the sleeping thread to yield the
> execution time for other threads.
> The questionable behavior might occur in case of sleep(0); (should it
> yield the remaining time or just return immediately - up to the
I presume most of the systems would make the sleeping thread to yield the
execution time for other threads.
The questionable behavior might occur in case of sleep(0); (should it
yield the remaining time or just return immediately - up to the OS).
And multi-cpu might also do something different.
t
Hi All,
Can I use Sleep() in a thread to give up cpu time to other threads running
at the same time, so as to adjust the relative "niceness" of a group of
workers working on the same subject (in which each thread take part of the
whole task).
Thanks!
Xiangrong
___
On 02/25/2015 10:40 AM, Marco van de Voort wrote:
Strictly speaking it is possible to have interfaces to some external
entity that does not map to the own class type.
I suppose this is why Borland once invented them: not for the purpose
suggested in the "Blog", but to mirror some external wind
On 02/25/2015 10:40 AM, Marco van de Voort wrote:
They are not autocreating.
???
I seem to remember that I once did a test implementing an arithmetic
with interfaces and there was no need to call create. Maybe I am fooled
by my old brain.
-Michael
___
In our previous episode, Michael Schnell said:
> > Exactly. Interface delegation solves this problem, that is why it was
> > invented.
>
> How does this correspond to the fact that (AFAIK) interfaces are
> auto-creating, reference-counted and auto-destroying, while classes are
> not ?
>
> Ore
On 02/25/2015 10:16 AM, Marco van de Voort wrote:
But the only state in it is the self of the method to be synchronized. But
that can be enough (as Sven said)
Hadn't occured to me since I'm synchronizing msgs to a certain controller
context though (my "invoke" has a parameter controller and is r
On 02/24/2015 09:55 PM, Michael Van Canneyt wrote:
Exactly. Interface delegation solves this problem, that is why it was
invented.
How does this correspond to the fact that (AFAIK) interfaces are
auto-creating, reference-counted and auto-destroying, while classes are
not ?
Ore is this ju
In our previous episode, Michael Schnell said:
> >> will make the instance remoce itself.
> > You need a full queue for that, since the mainthread might not run till the
> > thread next queue()'s.
> The fpc RTL does implement a full blown queue for managing TThread.Queue
> and TThread.Synchronize.
On 02/24/2015 04:38 PM, Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
On this behalf, "Application.QueuAsyncCall" is more versatile.
But it's easy with TThread.Queue, as well.
- define a class (not to be derived from TThread) that holds the data
to be transferred
On 02/24/2015 05:17 PM, Sven Barth wrote:
Internally Closures are implemented as a class implementing an
interface that provides an Invoke method.
Great !
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.
19 matches
Mail list logo
