[fpc-pascal] Use sleep in thread

2015-02-25 Thread Xiangrong Fang
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

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread Xiangrong Fang
2015-02-25 22:47 GMT+08:00 Dmitry Boyarintsev skalogryz.li...@gmail.com: 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

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread Xiangrong Fang
2015-02-25 23:16 GMT+08:00 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); until ... ​This seems not what I want. I would like to

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread hinstance
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 xrf...@gmail.com:

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread Henry Vermaak
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 -

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread Michael Schnell
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: [fpc-pascal] Use sleep in thread

2015-02-25 Thread 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 OS). And multi-cpu might also do something different.

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread Henry Vermaak
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 of the

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread hinstance
I mean T.Suspend, so u resume it then suspend it 25.02.2015, 18:16, hinsta...@yandex.ru 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;   

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread Philippe Lévi
synchronising tools do not do what you want? De: fpc-pascal-boun...@lists.freepascal.org fpc-pascal-boun...@lists.freepascal.org em nome de Xiangrong Fang xrf...@gmail.com Enviado: quarta-feira, 25 de fevereiro de 2015 12:33 Para: FPC-Pascal users discussions

Re: [fpc-pascal] Use sleep in thread

2015-02-25 Thread fredvs
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;

Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

2015-02-25 Thread Michael Schnell
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

Re: [fpc-pascal] about interface and multiple inheritance

2015-02-25 Thread Marco van de Voort
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 is this

Re: [fpc-pascal] about interface and multiple inheritance

2015-02-25 Thread Michael Schnell
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

Re: [fpc-pascal] about interface and multiple inheritance

2015-02-25 Thread Michael Schnell
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

Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

2015-02-25 Thread Michael Schnell
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

Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

2015-02-25 Thread Michael Schnell
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

Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

2015-02-25 Thread Marco van de Voort
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. But

Re: [fpc-pascal] about interface and multiple inheritance

2015-02-25 Thread Michael Schnell
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