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.

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.

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

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.

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

select is basically what peekmessage does.

Michael.

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

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?

Does onidle need/use any of these?
And, there's always application.processmessages, which.. is poo pooed by many

loop in which to check at regular basis.

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

Sven Barth 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

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

But can it be used without threads at all without locking the app up