On Thu, 2 Dec 2010, Marcos Douglas wrote:
2010/12/2 Michael Van Canneyt <[email protected]>:
On Thu, 2 Dec 2010, Marcos Douglas wrote:
On Thu, Dec 2, 2010 at 1:12 PM, <[email protected]> wrote:
On Thu, 2 Dec 2010, Dariusz Mazur wrote:
W dniu 2010-12-02 11:38, [email protected] pisze:
On Thu, 2 Dec 2010, Dariusz Mazur wrote:
W dniu 2010-12-02 09:25, [email protected] 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).
This is correct, but I assume that when starting a web application, you
will start with a fresh design.
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)
I don't see the connection of these problems with how threads are used.
A simple WaitForEvent()/SetEvent() should do this.
3. With second attempt session data is computing with different threads,
thus thread vars can't be used
They are only a problem if you use global variables. You should never use
global variables, unless maybe the database connection and global
application configuration.
None of my 4 web applications uses global variables (except said database
connection and global configuration object). The other programmers have
not yet complained. They know global variables
are evil from their work on our regular desktop program :-)
How do you work to manipulate sessions?
There is a global sessionlist (simple hashlist: string is session GUID,
object is session module).
based on the session cookie, I get the session. All other things are stored
in a descendent of the session module.
There is just a global sessionlist accessed for many threads, at the same time?
The fpWeb framework manages thread conflicts?
No, it does not. The sessionlist is not in fpWeb (although I have planned that),
only in some private code (the list is obviously protected with a critical section).
What conflicts do you expect ?
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
