2010/12/2 Michael Van Canneyt <[email protected]>: > > > 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 ?
Conflicts type of Read/Write where 2 threads uses the same session, at the same time. But you said the list is protected with a critical section, so... that's ok. Now... why isn't in the fpWeb? :) Marcos Douglas -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
