On Tue, 10 Feb 2015, silvioprog wrote:
Buddy, I finally could make a draft of a FastCGI application running in
multi-thread in proxy mode. =)
Congratulations !!
It worked on:
. Windows 7 - 64 bits;
. nginx 1.7.9 com o módulo FastCGI distribuído nele;
. Apache 24 (httpd-2.4.12-win64-VC11.zip), que já vem com o módulo FastCGI com
suporte ao modo proxy;
. FPC do trunk.
And the steps to test it were:
. download and unzip the attached package, after unpacking it, enter the nginx
directory and apply its settings in your copy (ainda
não testei no Linux, mas farei isso em breve I haven't tested it on Linux yet,
but I'll do it soon);
. open and run the project1.lpr project;
. open a tab in the browser and access http://localhost:81/test?op=loop, it is
supposed to be frozen for 10 seconds;
. open another tab in the browser and access http://localhost:81/test, it is
supposed to show the current time, even with the first
tab frozen, this shows that the application is working in multi-thread.
I will test this ASAP :)
Follow attached a unit called mycustfcgi.pp, that is a copy of the trunk
custfcgi.pp. I've not created a patch because I believe that
it will enter a new class in this unit, probably called TFCGIThread, and it
won't be necessary a programmer treat the AcceptConnection
method externally and not create extra classes, like "TFastCGIThread" and
"TFastCGIRouter" as in the example.
Yes, Ideally, it should be simply a property 'Threaded' in TFastCGIApplication.
But, I have looked at the code, and I have several remarks/questions:
you create threads as requests come in.
This can easily explode. I would prefer an approach where there is a thread
pool,
with a size that can be set at startup, or at least a maximum number of threads
to start.
Do you think you can change the design so it uses a thread pool ?
Then: you create an instance of the FastCGIHandler for the request,
but you do not copy the handler's properties (event handlers and so on).
How is then for example the eventhandler OnIdle called ?
Maybe it is better to refactor the code so there is a separate 'FastCGIIOHandler' object
or something like it.
Another question.
As I see it, you create a thread per accepted connection.
Each connection can handle multiple requests.
All requests on a connection are handled within the same thread.
What about an approach where there is a pool of threads that handles requests ?
I believe that with some tips of you, I can make this implementation by myself
and then send a patch.
It would be great if this feature has already come in FPC 3.0, which is about
to be released. =)
We will see, I think this is a big feature, and that is "bad" because big
merges to fixes branch are not easily accepted.
Anyway: Great work !
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
