[fpc-devel] Android native application with local webserver

[Dariusz Mazur]

  W dniu 2011-04-14 16:08, Michael Schnell pisze:
> 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).
I've implement message queue (like in Windows), also VCL/LCL  style 
communication with widgets. TThread.synchronize was reimplement, because 
there is many "Main thread" - per each session. All enough to use the 
same source do build desktop and web application.


>
>> 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", 
No , I mean this is main thread of listen socket


> which is supposed to do most of the "Office Logic" work, 
"office logic" and changes in used widgets (controls)  is done in 
session thread, and when computing if finished,  request thread prepare 
response, based on new state of "visible" widgets, there are mutexes, to 
coordinate flow between this two threads.

> 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.

In my attempt single session (like desktop application) work in own 
thread. In session can be use inner threads, events, modal windows etc. 
similar like in desktop.

>>
>> 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.
Why. When server want to push to browser response earlier (response took 
less than 200ms including ping), when browser (user) want  ask, then 
send new request, no one wait


-- 
   Darek