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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
