[fpc-devel] Android native application with local webserver

Michael Schnell mschnell at lumino.de
Thu Apr 14 16:08:34 CEST 2011


On 04/14/2011 02:55 PM, Dariusz Mazur wrote:
> What is the problem when pthreads works?
In fact this supposedly is a Lazarus LCL problem, so we might be in the 
wrong discussion group here,

The LCL's "Application" object defines a main thread, that allows for 
"event driven programing" (the program flow stalls after the 
initialization using (close to) 0% CPU and e. g. TTimers fire "main 
thread events" that are queued in an "Event Queue" and handled one after 
the other as soon as possible when the time of one has come (waking up 
the main thread at this point).

Now the LCL provides the code that does this in (some of) its "Widget 
Type"- (aka "interface"-) implementations. There are several of those, 
but only those with a GUI binding do provide event driven programming. 
(Otherwise you could use a "noGUI" one for doing a kind of "WebGUI").

To allow for decent thread programming  in an environment with event 
driven programming, the threads need to be able to notify the (event 
driven) main thread by firing queue-able main-Thread events. This can be 
done by stuff like "TThread.Synchronize" (defined  in the RTL, but needs 
the help of the LCL <or whatever> ), "TThread.Queue" (not yet 
implemented, but available in Delphi), "Application.QueueAsychCall" 
(implemented in the LCL), and PostMessage (Windowish stuff, but quite 
decently cross-platform - implemented in the LCL).

> server work in own thread, each request in own, each session (whole 
> application for one user) in own
> communication between request thread and session threads are done via 
> FIFO queue
So the "Server" is the "Main Thread", which is supposed to do most of 
the "Office Logic" work, including handling the TTimer events. IMHO, 
it's not a good idea top do the Office Logic stuff directly in the 
threads that are fired by the single requests, as this will ask for huge 
problems with mutual access of commonly used data, which the user does 
not really want to handle with a great count of CriticalSections or 
similar synchronization stuff. I feel that it would be good to have the 
"requests" transformed to "main Thread Events", so that a "normal" (= 
not  thread aware) user is able to do the programming seeing only a 
single thread.
>
> I don't think so
> But when browser send request, server don't response at now, only wait 
> 30s and then (if its nothing to respond) send message to browser with 
> order to repeat request.
OK. If the program works only on request and the java code does a long 
sleep, the CPU use will be decently low. But of course this will not 
provide a very agile experience to the user.

Thanks a lot for making this work !

-Michael



More information about the fpc-devel mailing list