if events are better, why is aolserver multi-threaded?
gavino
any why is apache also?
where is a good event driven webserver?
Gerald W. Lester
> http://home.pacbell.net/ouster/threads.pdf
AOLserver is both event and multithreaded. The threads are for handling
blocking DB activity which AOL did a lot of.
> any why is apache also?
Because it was designed for C/C++
> where is a good event driven webserver?
TclHttpd and WUB
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Eric Hassold
People often get an opinion on this famous paper from John Ousterhout by
reading only its somehow provocative title.
But content never says thread are useless and should never be used. It
only explains thread model is intrinsically hard, requires expert
programmers, while event programming makes things easier to understand,
program, maintain and debug. Especially, when writing GUI applications,
events are better than threads.
Conclusion says "threads (are) more powerful than events, but power is
rarely needed". And to the question "should you abandon threads?", this
article clearly answers "NO, important for high-end servers (e.g.
databases)". Web servers, having to run under heavy load, enter
obviously into this category. Aolserver (together with some other Tcl
based servers) tries to offer best of two worlds, thanks ot Tcl's clean
thread model, using events as core model, and threads to scale
performance on multiple CPUs and to handle blocking operations (DB,
server-side scripts, etc...).
Last, those slides have been written in 1995. Comments applying to
high-end servers with multiple CPUs in 1995 get closer from our desktop
12 years later, with multi-core CPUs also delivered on entry-level PC.
> where is a good event driven webserver?
>
Lighttpd (http://www.lighttpd.net/), mathopd (http://www.mathopd.org/)
or Boa (http://www.boa.org/) come to mind. They are focusing on very
good performance for delivering static content and handling thousands of
concurrent connections. Such an events-based webserver is typically used
as off-load static server, living side by side with a more complex
(usually thread-based) server.
So, events are not better than threads, nor are threads better than
events. They both comes with pros and cons, and one has to choose the
one offering best tradeoff (or mixed of them) for a given context.
Eric
-----
Eric Hassold
Evolane - http://www.evolane.com/
Darren New
> TclHttpd and WUB
Does TclHttpd let you have two pages processing at once cleanly?
Right now, one of my web pages has to wait for other processes to catch
up and populate the database. At the moment, it sleeps several seconds
at a time until it sees a row come into the database with a timestamp at
or after the time the web page hit started.
I didn't see anything in TclHttpd that would lead me to believe such a
situation was easy. It looked more like "when you return from the
function we call, you better be finished processing, because we block
till you return and give to the user what you return to us."
Did I miss something?
--
Darren New / San Diego, CA, USA (PST)
I bet exercise equipment would be a lot more
expensive if we had evolved from starfish.
Jeff Hobbs
> Gerald W. Lester wrote:
>> TclHttpd and WUB
>
> Does TclHttpd let you have two pages processing at once cleanly?
>
> Right now, one of my web pages has to wait for other processes to catch
> up and populate the database. At the moment, it sleeps several seconds
> at a time until it sees a row come into the database with a timestamp at
> or after the time the web page hit started.
>
> I didn't see anything in TclHttpd that would lead me to believe such a
> situation was easy. It looked more like "when you return from the
> function we call, you better be finished processing, because we block
> till you return and give to the user what you return to us."
That is the general requirement for threads - to allow blocking db
access to process separately. Some dbs do have event-based processing
as well, but it is not as common. In the case above, you would want a
threaded web server (and both tclhttpd and wub have threaded operation
optional).
Jeff
Darren New
> That is the general requirement for threads - to allow blocking db
> access to process separately.
I may have been unclear. I'm not blocking on DB access. I'm blocking
while I wait for some *other* process to write into the DB.
I.e., the way it works now is
fetch row from database
while {timestamp on row < timestamp on start of web hit} {
after 3000
}
return formatted row from database
The client is waiting, but the server is waiting for some other server.
Since the wait could be as much as 30 seconds, I don't want to have a
thread for every hit if I can manage it.
What I'd like is to go
fetch row from database
if {timestamp on row < timestamp on start of web hit} {
stick into globals what we're waiting for
return
}
... top-level code ...
while {1} {
grab row from database
find all pending globals waiting for that timestamp
answer them all
Darren New
> fetch row from database
> while {timestamp on row < timestamp on start of web hit} {
> after 3000
> }
> return formatted row from database
--
Christian Nassau
> Gerald W. Lester wrote:
>> TclHttpd and WUB
>
> Does TclHttpd let you have two pages processing at once cleanly?
>
> Right now, one of my web pages has to wait for other processes to catch
> up and populate the database. At the moment, it sleeps several seconds
> at a time until it sees a row come into the database with a timestamp at
> or after the time the web page hit started.
>
> I didn't see anything in TclHttpd that would lead me to believe such a
> situation was easy. It looked more like "when you return from the
> function we call, you better be finished processing, because we block
> till you return and give to the user what you return to us."
>
> Did I miss something?
>
tclhttpd has Httpd_Suspend and Http_Resume, which allow you to
temporarily suspend a request when the necessary data is not yet
available. This is for example used by Httpd_ReturnFile, which is meant
to transfer big files without blocking other requests. Isn't that
somewhat similar to your requirements?
HTH,
C.
--
=> Christian Nassau, http://www.nullhomotopie.de
Darren New
> tclhttpd has Httpd_Suspend and Http_Resume, which allow you to
> temporarily suspend a request when the necessary data is not yet
> available.
Ah! I must have missed that in the docs. It sounds like what I need. Thanks!
(I'm just really sick of switching back and forth between PHP and Tcl at
this point. :-)
Jeff Hobbs
> Jeff Hobbs wrote:
>> That is the general requirement for threads - to allow blocking db
>> access to process separately.
>
> I may have been unclear. I'm not blocking on DB access. I'm blocking
> while I wait for some *other* process to write into the DB.
>
> I.e., the way it works now is
>
> fetch row from database
> while {timestamp on row < timestamp on start of web hit} {
> after 3000
> }
> return formatted row from database
>
> The client is waiting, but the server is waiting for some other server.
In general you want to use the form [after $delay $script] which
reschedules an event. Without the $script, it does pause that interpreter.
Jeff
Darren New
> In general you want to use the form [after $delay $script] which
> reschedules an event. Without the $script, it does pause that interpreter.
Right. And then you return from the procedure, and TclHttpd says "Oh,
you've returned an empty page to the browser." :-) And then, some time
later, the rest of the script runs and has no place to put its result.
But it looks like Christian Nassau has answered my questions. Thanks!
Eric Hassold
> Jeff Hobbs wrote:
>> In general you want to use the form [after $delay $script] which
>> reschedules an event. Without the $script, it does pause that
>> interpreter.
>
> Right. And then you return from the procedure, and TclHttpd says "Oh,
> you've returned an empty page to the browser." :-) And then, some time
> later, the rest of the script runs and has no place to put its result.
>
Not if you wait for the alarm to be raised from within your script. Your
sample code might be rewritten to look like:
set myAlarm 0
while {timestamp on row < timestamp on start of web hit} {
after 3000 [list incr myAlarm]
vwait myAlarm
}
This will behave exactly the same way, from your local point of view,
but Tcl event loop will run during the vwait, allowing TclHttpd to keep
on processing others pending requests.
> But it looks like Christian Nassau has answered my questions. Thanks!
>
Eric
Darren New
> This will behave exactly the same way, from your local point of view,
And from the global point of view, will nest a bunch and block until
everyone who called after me finishes. That's uncool.
Don Porter
> Christian Nassau wrote:
> > tclhttpd has Httpd_Suspend and Http_Resume, which allow you to
>> temporarily suspend a request when the necessary data is not yet
>> available.
>
> Ah! I must have missed that in the docs.
tclhttpd? docs? hahahahahahahaha.
DGP
Ron Fox
The question is a lot like which is better, a VW beetle or a
Pontiac Montana?
It's not a case of which is better. Both are useful programming
paradigms. Choose the scheme that most simply matches your needs.
Where concurrency is a requirement threads are needed, along with all
the real nasty issues about getting them to work without deadlock,
livelock, race conditions and so on. Where concurrency is not needed,
event driven software is a much simpler model to get to work right.
And where interactions are not user driven but program driven, even
simpler is just to let the program prompt and then compute...a style
that's gone out with the idea that all programs must have GUI's to be
useful.
Ron.