FCGIApp.CurrentFCGIThread.HandleRequest does not execute in the context of CurrentFCGIThread

[Moacir Schmidt]

Have you noticed that FCGIApp.CurrentFCGIThread.HandleRequest does not execute in the context of CurrentFCGIThread? I think this is not a good practice and can leave to unpredictable results in more compex applications...

[Phil]

On Friday, October 12, 2012 6:18:47 PM UTC-4, Moacir Schmidt wrote:

Have you noticed that FCGIApp.CurrentFCGIThread.HandleRequest does not execute in the context of CurrentFCGIThread? I think this is not a good practice and can leave to unpredictable results in more compex applications...

CurrentFCGIThread is deprecated, if that makes any difference.

Do you have more information (fuller explanation) or a fix?

Thanks.

-Phil
 

[Moacir Schmidt]

Sorry for the enormous delay. I was abducted by a very big project and had to hibernate....

Now I'm back to this issue. I came here looking for a statefull implementation of FastCGI in pascal. FCGIApp.pas was exactly what I needed.

The problem I mentioned before can be exemplified like this. Suppose that...

1) User A makes a request and FCGIApp creates FCGIThread 1. Lets call it as FCGIThread1

2) Same user A makes another request and FCGIApp creates FCGIThread2. FCGIThread2.Execute method calls FCGIThread1.HandleRequest (throught _CurrentFCGIThread).

Calling a thread method (FCGIThread1.HandleRequest) inside another thread (FCGIThread2) does not change thread context. This leaves to some problems. For me the problem is that I'm using dbexpsda SQL Server driver and it needs a call to CoInitialize that has to be done inside thread context.

I have no ideas how to handle this issue. Tried several approaches without success.

If someone could give me a north I really appreciate!

[nandod]

Hello,

1) User A makes a request and FCGIApp creates FCGIThread 1. Lets call it as FCGIThread1

2) Same user A makes another request and FCGIApp creates FCGIThread2. FCGIThread2.Execute method calls FCGIThread1.HandleRequest (throught _CurrentFCGIThread).

yep, this is an unusual design and I have faced a similar problem.

My take is that the webapplication object should probably not store threads but sessions (in a thread-safe list), and each new thread should take on the correct session and call HandleRequest on itself (and then free on terminate). I was planning to do such refactoring in kitto (which uses a modified version of ExtPascal) but I haven't got around to do it yet.

-- 

Nando

[Moacir Schmidt]

Hello, Nando!

yep, this is an unusual design and I have faced a similar problem.

My take is that the webapplication object should probably not store threads but sessions (in a thread-safe list), and each new thread should take on the correct session and call HandleRequest on itself (and then free on terminate). I was planning to do such refactoring in kitto (which uses a modified version of ExtPascal) but I haven't got around to do it yet.

I think this is not possible, since each http request (from same user A) generates a different connection into FCGIapp.

You cannot "merge" both connections into a single thread context. If I understood correctly, with your suggestion each HandleRequest will be executed into a different thread context.

If I'm wrong please give details! I'm really really interested in a solution for this issue and I have priority time to invest. If you have any approach please let us know and I promise trying to implement it.

[nandod]

Hello, Moacir.

My take is that the webapplication object should probably not store threads but sessions (in a thread-safe list), and each new thread should take on the correct session and call HandleRequest on itself (and then free on terminate). I was planning to do such refactoring in kitto (which uses a modified version of ExtPascal) but I haven't got around to do it yet.

I think this is not possible, since each http request (from same user A) generates a different connection into FCGIapp.

I see what you mean. Let me clarify: By "session" I mean all state information that you use to bind a request to a previous one. In this case, an instance of TExtSession. I don't mean HTTP requests. So this *is* possible, although it will not solve your problem, per se. You still need to call Coinitialize for each thread, but this is orthogonal to the problem (actually I now realize that my problem is different in nature than yours).

 

What you want, AFAIU, is that instead of calling HandleRequest on the target thread, it is resumed so it can handle the request in its own context (and suspended once the request is handled).

-- 

Nando

[Moacir Schmidt]

Yes! My approach will be to create a single global thread (called "Listener" thread) to receive http requests with some kind of session id. Each session id will be associated with a specific thread (called "Worker" thread) that I will maintain in a pool.

After recover the right worker thread I will set its variables with request info and resume the thread. To resume/sleep this worker thread I will use some kind of signaling (CreateEvent/SetEvent,WaitForSingleObject in Windows).

<Moacir>