[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