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

css css at swissjabber.ch
Thu May 29 10:08:43 UTC 2008


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



More information about the Tbnl-devel mailing list