Hi Christoph,
thank you for your explanation.
It would in fact be possible to use a specialized connection manager subclass that implements listen-for-connections so that it uses some form of select() to not only wait for new connections arriving, but also for data coming in on one of the current client sockets. I have not fully thought this through, but I am interested in supporting this mode of operation - Not only because the client that I work for wants persistent connections (which we can't currently support in single threaded mode), but also because the deployment problem that you describe hit me in the past as well. Having a Lisp that can run Hunchentoot on a small virtual Linux or even a shared web host would be very nice.
I will be discussing this with Edi next week, and depending on the outcome you may see the functionality added soon.
-Hans
On Thu, May 29, 2008 at 12:08 PM, css css@swissjabber.ch wrote:
Hello.
2008/5/29 Hans Hübner hans@huebner.org:
On Thu, May 29, 2008 at 10:00 AM, Edi Weitz edi@agharta.de wrote:
IIUC this could be possible with the current (unreleased) development version of Hunchentoot. Look at the "connection manager" class Hans has written and see if you can write your own connection manager to achieve what you want.
It was in fact my primary motivation to make the behavior of Hunchentoot with respect to threads more configurable, and I will be continuing on that road. A connection manager class that uses one thread for I/O scheduling and one or more request executor threads is on the list of things that I want to implement.
css, can you detail what you exactly want to achive? Why do you want to avoid threads?
One reason: I am using clisp, which has no real thread support. The other lisps use too much resources. And I have a very limited amount of threads. I am not a server admin of a huge server, I have to work with one of these tiny-low-cost-virtual-servers, which have very limited resources.
As far as I see at the moment, connection-listener could be useful, but since clisp has no stable thread support yet, while usocket does not have support for accepting connections on server-sockets without blocking (and clisp does), which may be the reason why you decided to use two threads instead of only one loop for accepting and processing. I would have to write stuff arount it, anyway. So it is maybe easier for me to just implement an own little HTTP-Server, though it is not trivial.
And, as a general note, if you want free support, can you at least supply us with something like a name so that it is easier to imagine a person behind your writing? Thank you.
I dont know why you can imagine a person you may have never seen better with his name, but ok, my name is no secret.
Regards, Christoph Senjak _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel