On 2013-09-18 09:20, Michael Van Canneyt wrote:
The fptimer unit implements a timer with a thread, but this forces the use of
threads on your application
The way I like it! ;-) Especially considering how thread friendly these
[common place] multi-core CPU's are these days.
Regards,
-
Conclusion:
Thus we could draft a living noGUI TCustomApplication sibling (aka
LCL WidgetType), that allows for firing MainThread Events triggered
from (a newly implemented) TTimer, TThread.Queue(),
TThread.Synchronize(), TApplication.QueueAsyncCall() and the legacy
windowish PostMessage() -
On Wed, 18 Sep 2013 09:32:54 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
It is really frustrating to see, that this now seems to solves the issue
I am hunting for since some five years.
Has it ever come to your mind that hunting might not be sufficient to
create code?
Over the
On 18.09.2013 10:00, Michael Schnell wrote:
On 09/18/2013 09:53 AM, Sven Barth wrote:
I wouldn't use the timeout constant for this. If you have two timers
of which the greatest common denominator is 1, but nevertheless rather
large (e.g. two primes) then you'd loop unnecessarily (I know this
On Wed, 18 Sep 2013, Sven Barth wrote:
On 18.09.2013 09:32, Michael Schnell wrote:
- TTimer is implemented including defining the timeout constant for
calls to CheckSynchronize() as the greatest common denominator of the
Time property of all enabled TTimer instances in the project (i.e. a
On 09/18/2013 10:05 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 09:32:54 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
Instead I was told that I should look at the LCL
source code and that in Windows, the Event queuing mechanism is done by
Windows itself and in Linux it is done
On Wed, 18 Sep 2013 10:25:43 +0200
Michael Schnell mschn...@lumino.de wrote:
On 09/18/2013 10:05 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 09:32:54 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
Instead I was told that I should look at the LCL
source code and that in
On 09/18/2013 10:38 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 10:25:43 +0200
Michael Schnell mschn...@lumino.de wrote:
What non-GUI events - additionally to the events I mentioned - would be
needed for the whole event system of the LCL ?
For example PostMessage can send messages to
Al 18/09/13 09:32, En/na Michael Schnell ha escrit:
It is really frustrating to see, that this now seems to solves the issue
I am hunting for since some five years.
Perhaps if you spent your time actually using fpc instead of hunting for
non-problems you'd have realized that this worked five
On Wed, 18 Sep 2013 10:55:34 +0200
Michael Schnell mschn...@lumino.de wrote:
On 09/18/2013 10:38 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 10:25:43 +0200
Michael Schnell mschn...@lumino.de wrote:
What non-GUI events - additionally to the events I mentioned - would be
needed for
In our previous episode, Michael Schnell said:
The fptimer unit implements a timer with a thread, but this forces the
use of threads on your application which is not always desirable.
Should be doable, as well. AFAIK, mse (for Linux) uses signals on that
behalf. We might want to steal
On 09/18/2013 01:26 PM, Marco van de Voort wrote:
While there is sigalarm, but can you have multiple independent timers
in an application that way?
I don't know. We would need to ask mse.
-Michael
___
fpc-pascal maillist -
On Wed, Sep 18, 2013 at 01:26:46PM +0200, Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
The fptimer unit implements a timer with a thread, but this forces the
use of threads on your application which is not always desirable.
Should be doable, as well. AFAIK,
In our previous episode, Sven Barth said:
forced to by hand use Windows messages to schedule asynchronous Main
Thread events.
TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So
that's definitely not very early.
D2006 afaik.
On 09/18/2013 05:03 PM, Sven Barth wrote:
TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So
that's definitely not very early.
OK, at least four years ;-) .
I have Turbo Delphi. Here it is implemented but not to be found in the
help.
-Michael
On Wed, Sep 18, 2013 at 03:57:36PM +0200, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
Should be doable, as well. AFAIK, mse (for Linux) uses signals
on that behalf. We might want to steal some ideas there.
While there is sigalarm, but can you have
On 09/13/2013 07:08 PM, Sven Barth wrote:
As we have already written in some previous mails to there is a global
event procedure to wake up the main thread that is triggered when
something is queued. The LCL uses this already and other programs
could use a TEvent or whatever.
Could you
In our previous episode, Michael Schnell said:
As we have already written in some previous mails to there is a global
event procedure to wake up the main thread that is triggered when
something is queued. The LCL uses this already and other programs
could use a TEvent or whatever.
On 09/16/2013 11:14 AM, Marco van de Voort wrote:
If you mean integrate with your own eventloop, then yes, make sure
that your idle event in your eventloop calls checksyncrhonize
OK, so checksynchronize() is the correct name of the RTL-provided
function that pulls the event queue. (Sorry that
In our previous episode, Michael Schnell said:
OK, so checksynchronize() is the correct name of the RTL-provided
function that pulls the event queue. (Sorry that the correct name
escaped from my silly brain.)
Yes, it is the connection between VCL and RTL for this kind of stuff.
AFAIU this
On 09/16/2013 01:22 PM, Marco van de Voort wrote:
The non-LCL one must simply call checksynchronize as the blocking part
of the mainthread's eventloop.
Thus, my wish already seems to be fulfilled.
Great !
there is no LCL dependence in theory, but other eventloop systems
might assume they
Am 16.09.2013 10:58, schrieb Michael Schnell:
On 09/13/2013 07:08 PM, Sven Barth wrote:
As we have already written in some previous mails to there is a
global event procedure to wake up the main thread that is triggered
when something is queued. The LCL uses this already and other
programs
Am 16.09.2013 13:22, schrieb Marco van de Voort:
Did I understand you correctly that there is a notifying procedure,
that is called by the Event queuing mechanism each time an event is
pushed onto the queue ?
That was not me, but Sven or sb else. But as I understood it, the queue
method does
Am 16.09.2013 13:38, schrieb Michael Schnell:
there is no LCL dependence in theory, but other eventloop systems
might assume they themselves implement the blocking part. (e.g. to
wake up because of OS messages) Services, console network server
implementations etc probably already do that both
On 09/16/2013 02:03 PM, Sven Barth wrote:
CheckSynchronize has a timeout parameter:
http://www.freepascal.org/docs-html/rtl/classes/checksynchronize.html
Great !
Maybe the docs should be updated and mention TThread.Queue, which for me
is most important, as it - finally - allows for decent
On 09/16/2013 02:01 PM, Sven Barth wrote:
WakeMainThread
Thanks for the pointer.
I'll take another look there.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 09/16/2013 02:01 PM, Sven Barth wrote:
( http://www.freepascal.org/docs-html/rtl/classes/wakemainthread.html ).
IIRC, TThread.Queue does this, as well.
Thus updating this page might be appropriate...
Thanks,
-Michael
___
fpc-pascal maillist -
Thanks for the clear information.
Enhanced by the knowledge about TThread.queue It will allow me to do
some nice tricks.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Thursday, September 12, 2013 7:14 AM, Michael Schnell mschn...@lumino.de
wrote:
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement
On 09/13/2013 06:06 AM, wkitt...@windstream.net wrote:
would this hamper or cause problems with normal non-gui programs using
the library?
1) This feature of course should only be provided additionally to the
functions we know and love.
2) Other than the work-alike
Am 13.09.2013 10:47 schrieb Michael Schnell mschn...@lumino.de:
On 09/13/2013 06:06 AM, wkitt...@windstream.net wrote:
would this hamper or cause problems with normal non-gui programs using
the library?
1) This feature of course should only be provided additionally to the
functions we know
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's telnet
client running in the program so would rather stick to the same
library if possible.
AFAIK, Lnet does not do threading internally (as does AsyncPro or -
partly - Indy),
Michael Schnell wrote:
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's telnet
client running in the program so would rather stick to the same
library if possible.
AFAIK, Lnet does not do threading internally (as does AsyncPro
Mark Morgan Lloyd wrote:
Is it feasible to use lnet for a simple TCP daemon on Linux, i.e. wait
for a connection on a predefined port, read as much data as is
available, repeat? And if so, what does the SerSock parameter to
Accept() represent?
I'd normally use a thread for this, but I've
Mark Morgan Lloyd wrote:
Michael Schnell wrote:
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's
telnet client running in the program so would rather stick to the
same library if possible.
AFAIK, Lnet does not do threading
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in the Main
Thread when something comes in (or
On Thu, 12 Sep 2013, Michael Schnell wrote:
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events
Michael Schnell wrote:
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in the Main
Thread when
In our previous episode, Mark Morgan Lloyd said:
common request, and since the fpc-Team some time ago enabled
TThread.Queue in the RTL, this is doable in a straight forward,
fpc-ish way (portable but Delphi compatible).
Although for certain types of usage being able to get directly to
On 09/12/2013 01:28 PM, Michael Van Canneyt wrote:
The very reason I use Synapse is that it DOES NOT use threads.
Synapse is simple to use. Keep it so.
Of course I don't vote for Synapse always using threads, but to provide
_additional_ functions / objects (maybe units) that work similar to
In our previous episode, Michael Schnell said:
The very reason I use Synapse is that it DOES NOT use threads.
Synapse is simple to use. Keep it so.
Of course I don't vote for Synapse always using threads, but to provide
_additional_ functions / objects (maybe units) that work similar to
On 09/12/2013 02:45 PM, Marco van de Voort wrote:
E.g. TComport only starts an helper thread if you register receive
events. If you do not, you can use it in a select/waitformultiple like
way in a thread.
Sounds good.
I'm going to test this ASAP.
-Michael
Is it feasible to use lnet for a simple TCP daemon on Linux, i.e. wait
for a connection on a predefined port, read as much data as is
available, repeat? And if so, what does the SerSock parameter to
Accept() represent?
I'd normally use a thread for this, but I've already got lnet's telnet
43 matches
Mail list logo
