Hi,

does anyone know if the TCustomFCgiApplication is multithreaded ?

Regards,

Dimitrios Chr. Ioannidis wrote

does anyone know if the TCustomFCgiApplication is multithreaded ?

What do you mean by "is multithreaded" ?

-Michael

Dimitrios Chr. Ioannidis wrote

Hi, does anyone know if the TCustomFCgiApplication is multithreaded ?

No, it is not.

It's on my todo list, but has low priority.

Michael.

While enhancing TCustomFCgiApplication regarding threads, TThread.Synchronize, TThread.Queue would need to be usable.

I suppose (in FCGI or similar) a "Thread" should be able to be kept running while the Browser is disconnected (no HTTP request running).

IMHO a very interesting issue here is Server to Browser signaling. In the past I learned that the straight CGI-compatible method ("Comet" and friends) does not work decently but nowadays, "WEBSockets" is supported by all relevant browsers and can be used for this.

TCustomFCgiApplication is used in Lazarus (wbelazideinterf.pas).

While enhancing it regarding threads, IMHO it would be a most sensible goal to do a Lazarus "Application type" / "WidgetType", that additionally to TThread.Queue, allows for TTimer and Application.QueueAsyncCall.

-Michael

Ηι,

Στις 2/5/2014 12:05 μμ, ο/η Michael Van Canneyt έγραψε:.

I'll try to see if i can help, do you have any hints or tips reg. the source ?

regards,

Dimitrios Chr. Ioannidis wrote

I'll try to see if i can help, do you have any hints or tips reg. the source ?

Let me know what you are about to do. Maybe I can be helpful on that behalf.

-Michael

There is a websockets implementation: search for bauglir websockets.

The two technologies HTTP and websockets are unrelated. The websocket simply uses the HTTP headers as a start, but the rest of the protocol is completely different.

I see you are still determined to push your ideas. Please, Please, please, do everyone a favour and get started on it.

All the time you spent on mails about this by now dwarfs the time needed to actually implement it.

Michael.

Well, I suggest you copy and start from zero;
I doubt it is possible to use the current unit as a single basis for a threaded and non-threaded implementation.

Michael.

Michael Van Canneyt wrote

I see you are still determined to push your ideas.

Is it nasty "pushing" just to state what you think is going to be useful for the community, when the chance occurs ?

Please, Please, please, do everyone a favour and get started on it.

In fact, right now I do have a concept in my head that really might work (i.e. can sensibly be done without the need to completely re-do the internals of the WidgetType stuff in the LCL which obviously does not make sense) .

I immediately would start, if I would have the spare time and/or the need. I _can_ do some researching as a background task and collect the results for me or anybody else who might be interested. When I started the research, I did have the need, as I was willing to do a large project that runs in a headless embedded Linux box. Unfortunately the company's focus changed towards a (lower featured) non-Linux implementation :-( .

All the time you spent on mails about this by now dwarfs the time needed to actually implement it.

I don't really agree. Even a long lasting mere research _is_ helpful. As well for me as for everybody else who might might be willing to implement something useful, because he either has the spare time or the need to use it.

In fact, during this low priority research, I only recently came across WebSockets. If I would have actually started to implement anything before, silly me would have ignored this possibility. Right now, I am positive that an implementation of something that might finally result in a Web GUI (similar to what "ExtPascal" was up to, nowadays based on - say - "CustomDrawn" and a JavaScript that implements a limited count of "basic" widgets in the Browser) should actually done based on

In fact I am watching CustomDrawn and - even some spare time available - I would not start to implement anything (that in fact should support both "embedded WEB GUI" as "CGI") before I am rather convinced that I can do this based on CustomDrawn.

-Michael

It becomes nasty, if you repeat it for the bazillionth time.

I agree about the usefullness of research.
But unlike you, I don't think these mails qualify as research.

MseGUI has a event-loop application type that runs without gui. I doubt it took martin a day to implement it; probably even less than half a day.

Michael.

Michael Van Canneyt wrote

I don't think these mails qualify as research.

I am sorry for potentially having used inappropriate wording. I got lots of very useful information from answers in these extremely helpful lists, that indeed led to me thinking to being finally able to do such an implementation (given enough spare time).

MseGUI has a event-loop application type that runs without gui.

The event loop issue has long been solved for me. I.e. since the implementation of TThread.Queue (that in fact has been triggered by one of my posts on that behalf) is in place (within the fpc rtl).

TThread.Queue finally clearly shows that - for allowing decent Event-oriented programming - implementing an event queue (or in fact using the one existing in the rtl) without the LCL (or msegui) is viable - and seemingly in fact rather easy. I now know that I could do such a thingy (including a draft of a TTimer implementation) with not too much effort (given a little bit of spare time).

Here the lacking documentation and the (for me) misleading name of "CheckSynchronize" (that in fact is the event queue managing call, handling as well TThread.Synchronize and TThread.Queue) prevented me from realizing that the fpc rtl already does provide an event queue implementation. Here silly me seemingly did misunderstand some helpful hints, I got in the forums a long time ago (while many other hints were in fact misleading as, like myself, the posters did not know about the existence of the Event queue in the rtl and recommended to create my own queue in the LCL - which I found close to impossible for "newcomers" to do in a way decently consistent with the ways the LCL is crafted. (I did start such a project but gave up.)

I doubt it took martin a day to implement it; probably even less than half a day.

Some years ago, I did take a deep look at the code in msegui that implements the event queue (independent form the queue in the fpc rtl). Martin would have needed to type all that day without thinking a second for inputting the source files. He es excellent, but not that almighty :-) .

But anyway, during the said research I found that doing another implementation of an event queue is not necessary, the one in the rtl should be just fine. So this seems very doable. and this is why I in this thread recommended to take a to the maintainers of fpc and all other list members for much insight I got during these years !

-Michael

On 05/05/2014 04:36 AM, Michael Schnell wrote:
...

Thanks to the maintainers of fpc and all other list members for much insight I got during these years !

And I thank you Michael for bringing these issues up! I'm glad to learn a little more from your recent messages.

This sort of reminds me of my favorite threads (on exceptions) back in
2001. The main point is that there are critical industrial uses of Delphi where things are *much* different than the normal Windows database app. Here are two messages that are related:

http://codenewsfast.com/cnf/article/0/permalink.art-ng1253q88944

http://codenewsfast.com/cnf/article/0/permalink.art-ng53q201750

Best regards,
Paul
www.TurboControl.com

Paul Breneman wrote

I'm glad to learn a little more from your recent messages.

As you are interested I am happy to provide some more information.

In msegui, the EventQueue is done using a decently structured construct of classes that allows for creating any type of information queues. As in Lazarus the GUI based WidgetTypes all use implement own dedicated event queue code, using an msegui based construct IMHO would only makes sense if all appropriate queues in the LCL would be done on that base. I of course am not in a position to trigger such a re-construction. So I gave up on that idea for such a "small" and seldom used Widget Type as I have in mind.

When doing a not GUI based Widget Type (for embedded and/or CGI use) using just the Event queue that is implemented in the fpc rtl, a very basic and rather inaccurate but platform independent TTimer implementation could be done managing the Timeout parameter of "CheckSynchronize" according to the needs of all active instances of TTimer. A more accurate implementation would need to use OS features such as timers or threads and push events onto the queue.

When doing such a WidgetType, "Application.QueueAsynCall" would need to be implemented in a way that it pushes events onto the said queue.

-Michael

I in fact just took the time to start implementing an "active noGUI" Widget Type for Lazarus.

Seems indeed rather easy up til now. (A single timer and TThread.Queue do work on Linux)

-Michael

I think I now have something that might be worth testing...

-Michael

Michael Schnell wrote

I think I now have something that might be worth testing...

Presumably we can expect a result by the year 2046 ? ;)

Michael.

Michael Van Canneyt wrote

Presumably we can expect a result by the year 2046 ? ;)

Getting Off-Topic.....

In fact I would like to have somebody else take a look at the code before I ask how to implement it in the LCL as a "WidgetType" activated by setting the project variable "WidgetType" to "ActiveNoGui" (and by selecting the Project type ActiveNoGui when doing a New->Project).

Here is what I have and have tested to seemingly decently work (in X86 32 Bit Linux):

- A TApplication class based TCustomApplication in the RTL
- A TCustomForm class (independent form but compatible with the TCustomForm implementations for the different Widget Types LCL)
- A TTimer class (independent form but compatible with the TTimer implementations for the different Widget Types LCL)

A testing project that consists of:
- An lpr file done in the same way as an lpr file for any Lazarus "Application"
- A unit that holds a TForm descendant (class and implementation) with the testing code for two TTimers and a TThread.

The timers and TThread.Queue work as expected.

The file "interfaces.pas" for this WidgetType, that holds the code for TApplication, TCustomForm and TTimer is just some 300 Lines, as it was not necessary to implement an Event Queue. Just using the queue the RTL provides is enough.

Todo:

Application.QueueAsyncCall (supposedly no problem, I know how to do that).

Do we need an emulation for PostMessage ?

What else ?

Thanks for listening,
-Michael

On 26-Sep-2004 Kristofer Skaug wrote (links below to messages): "You want mission critical? Consider the infrastructure for the Rosetta comet chaser, that will need to stay operational until 2014-2015." and he wrote: "Yep, we make these things... using BCB for all the "on-the-bare-iron" programming tasks."

Interesting stuff to go back and read with things currently happening: http://blogs.esa.int/rosetta/

This was cross posted to the Lazarus forum and there are a few more interesting links added there:
http://forum.lazarus.freepascal.org/index.php/topic,26419.0.html

This Lazarus forum message has a bit more:
http://forum.lazarus.freepascal.org/index.php/topic,25412.msg154279.html#msg154279