[hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread

[Hans Hübner]

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 at swissjabber.ch> wrote:
> Hello.
>
> 2008/5/29 Hans Hübner <hans at huebner.org>:
>> On Thu, May 29, 2008 at 10:00 AM, Edi Weitz <edi at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>