[Lazarus] GUI development for web UI

Dariusz Mazur darekm at emadar.com
Thu Dec 2 16:48:41 CET 2010

  W dniu 2010-12-02 11:38, michael.vancanneyt at wisa.be pisze:
> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>> W dniu 2010-12-02 09:25, michael.vancanneyt at wisa.be pisze:
>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>>>>>> ExtPascal uses threads to handle multiple connections. I remember 
>>>>>> you
>>>>>> don't accept this way, right? BTW, what is there wrong if ExtPascal
>>>>>> uses threads?
>>>>> I accept using threads, but not the way ExtPascal does it. Threads 
>>>>> should be
>>>>> optional. In extpascal, the thread is equal to the session: if you 
>>>>> have many
>>>>> sessions, the application will create as many threads as there are 
>>>>> sessions.
>>>> I use different architecture: each session has own thread and each 
>>>> connection has own thread. Sessions are separated from connections 
>>>> and communicate via FIFO queue.
>>>> Session runs whole life time in the same thread. With this i can 
>>>> use modal form and thread var in the same manner, as normal 
>>>> (desktop) application.
>>> I understand this is the easy way.
>>> But you don't need this architecture to do that. As long as a single 
>>> request
>>> runs in a single thread, there is no problem with decoupling 
>>> sessions and
>>> threads, and still be able to keep everything in memory.
>> I dont understand.
>> I parse single request in single thread (for each request new thread)
>> and what can I do (other) with sessions?
> One scenario looks like this:
> - Request comes in (on whatever thread).
> - Determine session data (your form) for the request.
>   Session data is in a global list.
> - Find a thread to handle the request.
> - Pass session data to thread and let it handle request.
> Another way is
> - Connection is accepted.
> - An idle thread to handle request is found.
> - Thread looks up session data from data in request.
> - Thread handles request using found session data.

At the beginning I use second attempt, after that first. But both have 
limitation, because not follow (not act as desktop OS) desktop architecture.
There are  not pass to more complicated application (when it is porting 
from Delphi).

1. All task of application should be prepare as response for request, 
there is problem with modal forms, which stop and wait to user action, 
and after response go on (next statement in current procedure, not other ).
2.  When application is busy for long time with preparing response, its 
no chance to make simple response with message of waiting (or progress bar)
3. With second attempt session data is computing with different threads, 
thus thread vars can't be used


More information about the Lazarus mailing list