Best way to check SimpleIPC for messages

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Best way to check SimpleIPC for messages

noreply
Is the best general way to check IPC messages in SimpleIPC to spawn a
thread? and check

I noticed in fpgui sample apps that use simpleipc, graemeg checks the
messages in the fpgui OnIdle event, AFAICT, not a separate thread. But
what if you are running a console mode program that has no onidle event?

Obviously "avoid threads where possible" but only if there is a simpler
mechanism not reinventing a thread. So it seems to me onidle in fpgui is
a simpler way than creating a new separate thread yourself, but how to
do it in a program that has no fpgui onidle?

On that note what would a lazarus app generally do to check for
messages, without locking the app up? A similar OnIdle solution?

Making some progress on the SimpleIPC DLL for any programming language,
but trying to figure out whether the end user of the dll should create
his own thread to check for ipc messages, or have the dll do it for him
to simplify, then fire a callback when message received.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

Michael Van Canneyt


On Fri, 12 May 2017, [hidden email] wrote:

> Is the best general way to check IPC messages in SimpleIPC to spawn a
> thread? and check
>
> I noticed in fpgui sample apps that use simpleipc, graemeg checks the
> messages in the fpgui OnIdle event, AFAICT, not a separate thread. But
> what if you are running a console mode program that has no onidle event?
>
> Obviously "avoid threads where possible" but only if there is a simpler
> mechanism not reinventing a thread. So it seems to me onidle in fpgui is
> a simpler way than creating a new separate thread yourself, but how to
> do it in a program that has no fpgui onidle?

Check manually. What else is left ?
There is no message queue, so no loop in which to check at regular basis.

> On that note what would a lazarus app generally do to check for
> messages, without locking the app up? A similar OnIdle solution?

Yes. The sample programs check in Application.OnIdle.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

Michael Schnell
On 12.05.2017 16:37, Michael Van Canneyt wrote:
>
> Check manually. What else is left ? There is no message queue, so no
> loop in which to check at regular basis.
>
For event processing in a not threaded project or in the main thread of
a threaded project you at best use the Event Queue provided by some
Infrastructure library (e.g. LCL or mse). IMHO, SimpleIPC might makes
sense, if you don't want to use one of those. (mse and an enhanced NoGui
LCL "Widget Type", I have done a working draft for, can provide a
message queue even with no binding to a GUI Widget Set).

But when using SimpleIPC for signaling to another process (executable,
e.g.  a Lazarus "Application" ) I suppose, you  need a thread to avoid
latency and/or huge CPU demand by polling to transfer the event to the
Main Thread via the Event Queue (e.g. by Application.QueueAsyncCall or
TTherad.Queue).

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

noreply
In reply to this post by Michael Van Canneyt
On 2017-05-12 09:37, Michael Van Canneyt wrote:
>> Obviously "avoid threads where possible" but only if there is a
>> simpler mechanism not reinventing a thread. So it seems to me onidle
>> in fpgui is a simpler way than creating a new separate thread
>> yourself, but how to do it in a program that has no fpgui onidle?
>
> Check manually. What else is left ? There is no message queue, so no
> loop in which to check at regular basis.


What's left is possibly something like apache 1.3 source code which
somehow, AFAIR avoids using threads by using some other obscure strange
thing, which I have forgotten. Possibly something like old dos programs
used (sorry, not a Dos programmer, don't know.. not old enough).

Quote from some slashdot comment:
"There is an Apache2 mpm, called "prefork", which isn't threaded and
basically makes Apache2 look like Apache1. But hey, we have a very good
server already that looks like Apache1."

Some people have magically figured out how to avoid threads using
possibly bizarre techniques..

Quote " It handles requests in a manner similar to Apache 1.3. It is
appropriate for sites that need to avoid threading for compatibility
with non-thread-safe libraries. It is also the best MPM for isolating
each request, so that a problem with a single request will not affect
any other."

I looked into the apache 1.3 sources before to figure out what they
used, but long forgotten now.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

Michael Van Canneyt


On Mon, 15 May 2017, [hidden email] wrote:

> On 2017-05-12 09:37, Michael Van Canneyt wrote:
>>> Obviously "avoid threads where possible" but only if there is a
>>> simpler mechanism not reinventing a thread. So it seems to me onidle
>>> in fpgui is a simpler way than creating a new separate thread
>>> yourself, but how to do it in a program that has no fpgui onidle?
>>
>> Check manually. What else is left ? There is no message queue, so no
>> loop in which to check at regular basis.
>
>
> What's left is possibly something like apache 1.3 source code which
> somehow, AFAIR avoids using threads by using some other obscure strange
> thing, which I have forgotten. Possibly something like old dos programs
> used (sorry, not a Dos programmer, don't know.. not old enough).

They use select (or poll) and fork. So the equivalent of threads.
mpm = multi process module.

select is basically what peekmessage does.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

Michael Schnell
On 16.05.2017 07:30, Michael Van Canneyt wrote:
>
> select is basically what peekmessage does.
>
AFAIK "select()" (and - more versatile -  "<e>poll()"  ) in Linux uses
an appropriate system call to wait on one of multiple events (i.e.
devices, including e.g. pipes, which might be used by IPC). (Despite the
name) it does not do any "busy wait" ("polling"). So it's can be used
(instead of waiting in a blocking read)  in a worker-thread of an
"application". It's perfectly useful in an program without a message
queue provided by LCL or the mse-library.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

noreply
In reply to this post by Michael Schnell
On 2017-05-15 04:36, Michael Schnell wrote:

> On 12.05.2017 16:37, Michael Van Canneyt wrote:
>>
>> Check manually. What else is left ? There is no message queue, so no
>> loop in which to check at regular basis.
>>
> For event processing in a not threaded project or in the main thread
> of a threaded project you at best use the Event Queue provided by some
> Infrastructure library (e.g. LCL or mse). IMHO, SimpleIPC might makes
> sense, if you don't want to use one of those. (mse and an enhanced
> NoGui LCL "Widget Type", I have done a working draft for, can provide
> a message queue even with no binding to a GUI Widget Set).
>

Isn't that what the application onidle is for, a way to check messages
using the application code in the LCL

But a question is (sorry I am not familiar with "onidle"), what happens
when the application is not idle, but sort of idle? What classifies an
idle state? i.e. what if the cpu is at 3 percent consumption, or 55
percent, or 2 percent? What classifies an onidle? this documented
somewhere?
Is onidle reliable or hit and miss where the app is not idle enough, in
some cases?

> But when using SimpleIPC for signaling to another process (executable,
> e.g.  a Lazarus "Application" ) I suppose, you  need a thread to avoid
> latency and/or huge CPU demand by polling to transfer the event to the
> Main Thread via the Event Queue (e.g. by Application.QueueAsyncCall or
> TTherad.Queue).

Does onidle need/use any of these?
And, there's always application.processmessages, which.. is poo pooed by
many
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

Free Pascal - General mailing list

Am 17.05.2017 07:08 schrieb <[hidden email]>:
>
> On 2017-05-15 04:36, Michael Schnell wrote:
>>
>> On 12.05.2017 16:37, Michael Van Canneyt wrote:
>>>
>>>
>>> Check manually. What else is left ? There is no message queue, so no loop in which to check at regular basis.
>>>
>> For event processing in a not threaded project or in the main thread
>> of a threaded project you at best use the Event Queue provided by some
>> Infrastructure library (e.g. LCL or mse). IMHO, SimpleIPC might makes
>> sense, if you don't want to use one of those. (mse and an enhanced
>> NoGui LCL "Widget Type", I have done a working draft for, can provide
>> a message queue even with no binding to a GUI Widget Set).
>>
>
> Isn't that what the application onidle is for, a way to check messages using the application code in the LCL
>
> But a question is (sorry I am not familiar with "onidle"), what happens when the application is not idle, but sort of idle? What classifies an idle state? i.e. what if the cpu is at 3 percent consumption, or 55 percent, or 2 percent? What classifies an onidle? this documented somewhere?
> Is onidle reliable or hit and miss where the app is not idle enough, in some cases?

OnIdle() is called when there is no more event waiting in the widgetset's event queue, basically meaning that the application has nothing better to do anyway. It has nothing to do with CPU usage.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

noreply
On 2017-05-17 00:54, Sven Barth via fpc-pascal wrote:
> OnIdle() is called when there is no more event waiting in the
> widgetset's event queue, basically meaning that the application has
> nothing better to do anyway. It has nothing to do with CPU usage.
>

That makes sense.
And recursively what happens if you call an event, inside the onidle,
...

Recursive nightmare, or not a problem?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

Mattias Gaertner
On Wed, 17 May 2017 01:50:32 -0500
[hidden email] wrote:

> On 2017-05-17 00:54, Sven Barth via fpc-pascal wrote:
> > OnIdle() is called when there is no more event waiting in the
> > widgetset's event queue, basically meaning that the application has
> > nothing better to do anyway. It has nothing to do with CPU usage.
> >  
>
> That makes sense.
> And recursively what happens if you call an event, inside the onidle,
> ...
>
> Recursive nightmare, or not a problem?

Not a problem for the LCL, but it may be a problem for your application.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

Michael Schnell
In reply to this post by noreply
On 17.05.2017 07:08, [hidden email] wrote:
>  what happens when the application is not idle, but sort of idle?

A new Queue event also only is serviced when no other previous events
are peresent hence when the application gets "idle".

I don't know when exactly "OnIdle" is called. It can't be in a closed
loop otherwise any application would always use 100% CPU.

Hence "OnIdle" is bound to work with an even greater latency than a
decent queue entry like     TThread.Queue or Application.QueueAsyncCall.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Best way to check SimpleIPC for messages

noreply
In reply to this post by Michael Schnell
On 2017-05-16 04:55, Michael Schnell wrote:

> On 16.05.2017 07:30, Michael Van Canneyt wrote:
>>
>> select is basically what peekmessage does.
>>
> AFAIK "select()" (and - more versatile -  "<e>poll()"  ) in Linux uses
> an appropriate system call to wait on one of multiple events (i.e.
> devices, including e.g. pipes, which might be used by IPC). (Despite
> the name) it does not do any "busy wait" ("polling"). So it's can be
> used (instead of waiting in a blocking read)  in a worker-thread of an
> "application". It's perfectly useful in an program without a message
> queue provided by LCL or the mse-library.
>

But can it be used without threads at all without locking the app up
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Loading...