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,
- G
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 yo
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
_
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 18.09.2013 13:33, Michael Schnell wrote:
On 09/18/2013 01:19 PM, Mattias Gaertner wrote:
Some users asked about messages from/to other applications for nogui
LCL applications on Windows.
OK.
In fact to me it has been a completely silly concept of Borland's that
in early Delphi versions TTh
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 multiple independent timers in an
> > application that way?
>
> I thi
On Wed, 18 Sep 2013, Michael Schnell wrote:
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.
mse inverts the problem.
The timer implementation relies
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 we
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 - fpc-pascal@lists.freepasc
On 09/18/2013 01:19 PM, Mattias Gaertner wrote:
Some users asked about messages from/to other applications for nogui
LCL applications on Windows.
OK.
In fact to me it has been a completely silly concept of Borland's that
in early Delphi versions TThread.Queue was not documented (or in very
e
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 st
On Wed, 18 Sep 2013 10:55:34 +0200
Michael Schnell wrote:
> On 09/18/2013 10:38 AM, Mattias Gaertner wrote:
> > On Wed, 18 Sep 2013 10:25:43 +0200
> > Michael Schnell wrote:
> >
> >> What non-GUI events - additionally to the events I mentioned - would be
> >> needed for "the whole event system
On 09/18/2013 12:05 PM, Luca Olivetti wrote:
Perhaps if you spent your time actually using fpc instead of hunting
for non-problems ...
As already pointed out, I have no intention to do a Project of such kind
myself. I am just trying to construct a toolbox to help my colleagues to
port their D
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 09/18/2013 10:38 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 10:25:43 +0200
Michael Schnell 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 other applications
On Wed, 18 Sep 2013 10:25:43 +0200
Michael Schnell wrote:
> On 09/18/2013 10:05 AM, Mattias Gaertner wrote:
> > On Wed, 18 Sep 2013 09:32:54 +0200
> > Michael Schnell wrote:
> >
> >> [...]
> >> Instead I was told that I should look at the LCL
> >> source code and that "in Windows, the Event qu
On 09/18/2013 10:20 AM, Michael Van Canneyt wrote:
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 so
On 09/18/2013 10:09 AM, Sven Barth wrote:
I would not use Sleep as you need to be able to cancel the timer
A decent point ...
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 09/18/2013 10:05 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 09:32:54 +0200
Michael Schnell 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 by a queue in the
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 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 is
On Wed, 18 Sep 2013 09:32:54 +0200
Michael Schnell 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 time, there had
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 is
a constructed example, but nevertheless o
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
simple timer that accumulates delays impos
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(
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 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 -
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: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 pa
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 o
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 t
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 c
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 them
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
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 tha
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/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 el
Am 13.09.2013 10:47 schrieb "Michael Schnell" :
>
> 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
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 "Application.QueueAsyncCal
On Thursday, September 12, 2013 7:14 AM, 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 th
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
_
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 simil
On 09/12/2013 02:36 PM, Mark Morgan Lloyd wrote:
Although for certain types of usage being able to get directly to the
hardware (or strictly, to the lowest level the OS supports for normal
users) is absolutely essential, e.g. if timing information has to be
appended to each character or if re
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, 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 dire
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 s
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 in
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 an
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 int
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 al
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
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), so
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
cli
53 matches
Mail list logo
