Hello.
My problem may seem strange, but: I have a huge download to generate on my hunchentoot, and I dont want to have one thread for each of these downloads, but one thread answering multiple requests at the same time (since the generation takes time, caching takes space, and sending the generated code to multiple receivers seems the best idea to me).
That is, I want to get the request-object, and then pass it to another thread, who is then handling multiple requests (i.e. sending "non-waiting", polling for input, etc.). Is this possible?
That is, I want to get the request-object, and then pass it to another thread, who is then handling multiple requests (i.e. sending "non-waiting", polling for input, etc.). Is this possible?
I'm not sure I follow. Do you want to get the output stream (and/or the input stream) and pass that to another thread for processing? I don't know the answer, just trying to clarify.
Cheers, Chris Dean
2008/5/29 Chris Dean ctdean@sokitomi.com:
That is, I want to get the request-object, and then pass it to another thread, who is then handling multiple requests (i.e. sending "non-waiting", polling for input, etc.). Is this possible?
I'm not sure I follow. Do you want to get the output stream (and/or the input stream) and pass that to another thread for processing? I don't know the answer, just trying to clarify.
Cheers, Chris Dean
Hm. I guess what I want is best explained as some "Polling-Mode" for requests. I.e. having a main loop in one thread, "polling" or waiting for new requests, an then scheduling myself the input and output inside this one thread. My problem is that the number of threads I can use is bounded at a low bound, and I do not want to "waste" threads for something, that doesnt need them - i.e. I would like to schedule the requests and their processing myself, not relying on some threaded interface. I wonder if this is possible with hunchentoot.
Hm. Maybe some "pseudocode" shows, what I mean. I have a loop with the following "content"
(some-infinite-loop (if (new-connection-arrived) (push request requests-to-answer)) (dolist (req requests-to-answer) (continue-processing req) ; do some small action that continues the processing of req ))
That is, basically, what I want to do. Or at least something similar. Can this be done?
css css@swissjabber.ch writes:
Hm. I guess what I want is best explained as some "Polling-Mode" for requests. I.e. having a main loop in one thread, "polling" or waiting for new requests, an then scheduling myself the input and output inside this one thread. My problem is that the number of threads I can use is bounded at a low bound, and I do not want to "waste" threads for something, that doesnt need them - i.e. I would like to schedule the requests and their processing myself, not relying on some threaded interface. I wonder if this is possible with hunchentoot.
Sure, I got it. A very reasonable desire for a high performance server. I don't believe this is possible in Hunchentoot as it stands now - the current code is very thread based.
HTTP is a fairly simple protocol and you could use Hunchentoot as a starting point for implementing your system.
Cheers, Chris Dean
Sure, I got it. A very reasonable desire for a high performance server. I don't believe this is possible in Hunchentoot as it stands now - the current code is very thread based.
HTTP is a fairly simple protocol and you could use Hunchentoot as a starting point for implementing your system.
Hm. HTTP is not /that/ simple. You need at least three (simple, but still) parsers, then things like Chunked encoding (ok, i can use Chunga for this), and it takes a while to make it "stable". So I thought I could use at least parts of Hunchentoot - but seems like the "critical" Parts are heavily interdependent from the other stuff.
Thank you anyway.
On Thu, 29 May 2008 01:15:57 +0200, css css@swissjabber.ch wrote:
Hm. I guess what I want is best explained as some "Polling-Mode" for requests. I.e. having a main loop in one thread, "polling" or waiting for new requests, an then scheduling myself the input and output inside this one thread. My problem is that the number of threads I can use is bounded at a low bound, and I do not want to "waste" threads for something, that doesnt need them - i.e. I would like to schedule the requests and their processing myself, not relying on some threaded interface. I wonder if this is possible with hunchentoot.
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.
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?
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.
-Hans
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
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
2008/5/29 Hans Hübner hans@huebner.org:
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.
That is good. Anyway I started reading your code a little more (maybe I can write a quick-and-dirty-version for clisp in the meantime). What I actually didnt find was any place where the routines like listen-for-connections, etc., are really called, i.e. I cannot find any server-loop. However, I also cannot test your Code - seems like I am to stupid to understand this Trac-Thingy... (How) can I download/checkout/whatever the Code for hunchentoot from this server?
Thank you (and sorry for that stupid question)
Christoph
On Thu, May 29, 2008 at 6:23 PM, css css@swissjabber.ch wrote:
That is good. Anyway I started reading your code a little more (maybe I can write a quick-and-dirty-version for clisp in the meantime). What I actually didnt find was any place where the routines like listen-for-connections, etc., are really called, i.e. I cannot find any server-loop. However, I also cannot test your Code - seems like I am to stupid to understand this Trac-Thingy... (How) can I download/checkout/whatever the Code for hunchentoot from this server?
Sure, the easiest way to get Hunchentoot and all dependencies is:
svn co svn://bknr.net/svn/ediware
Let me know if it does not work for you.
-Hans
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.
Hi, If you decide to go with building your own simple http server, I will recommend you to look at mongrels parser. It's written in ragel but it's really trivial to use/import in Lisp (I did it for SBCL FFI, and it was damn easy, around 60 lisp lines or so) and it's pretty fast and secure. Just my 2 cents.
Cheers, V. Seguí
"Hans Hübner" hans@huebner.org writes:
css, can you detail what you exactly want to achive? Why do you want to avoid threads?
Just as a general piece of information, having an event-based style of programming (such as using Unix select) and avoiding or limiting the use of threads is a technique sometimes used for high load servers.
Dan Kegel's C10K is a good place to start if you're interested. http://www.kegel.com/c10k.html
Cheers, Chris Dean
-
Chris Dean -
css -
Edi Weitz -
Hans Hübner -
vseguip＠gmail.com