hello !
i want to write a web-based application in lisp :
- what is the best Common lisp implementation under windows with
multi-threading ( for server-side ) and free ? Now, i'm just seeing
Corman-Lisp.
- i've seen in some post that yahoo-store was made with CLisp ?? but
CLisp don't have multi-thread ? how could it work ?
ctu <·····@wanadoo.fr> wrote:
+---------------
| i want to write a web-based application in lisp :
|
| - what is the best Common lisp implementation under windows with
| multi-threading ( for server-side ) and free ? Now, i'm just seeing
| Corman-Lisp.
+---------------
I don't know about "best", but I've been using CMUCL with great success
(sitting between Apache and PostgreSQL), creating a CMUCL "process"
(green thread, really) per web hit.
-Rob
p.s. I've always wondered: Why do people call within-a-single-O/S-process
threads (a.k.a. coroutines) "green"?
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> p.s. I've always wondered: Why do people call within-a-single-O/S-process
> threads (a.k.a. coroutines) "green"?
I'd always believed it was due to Java. The oiginal team at Sun that
invented Java (then called Oak) was called Green, so I suppose it's
not unlikely that their original thread package would be called Green
Threads to distinguish it from the platform's native threads. FWIW,
see http://www.jguru.com/faq/view.jsp?EID=416246
I could be completely wrong, of course. Does anyone have a reference
to green threads that predates Java?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
On Fri, 15 Aug 2003 16:14:41 +0100, Daniel Barlow <···@telent.net>
wrote:
>····@rpw3.org (Rob Warnock) writes:
>
>> p.s. I've always wondered: Why do people call within-a-single-O/S-process
>> threads (a.k.a. coroutines) "green"?
>
>I'd always believed it was due to Java. The oiginal team at Sun that
>invented Java (then called Oak) was called Green, so I suppose it's
>not unlikely that their original thread package would be called Green
>Threads to distinguish it from the platform's native threads. FWIW,
>see http://www.jguru.com/faq/view.jsp?EID=416246
>
>I could be completely wrong, of course. Does anyone have a reference
>to green threads that predates Java?
>
>
Not to the "green" part ... I believe you are correct that the color
reference comes from Java. "User space" or simply "user" threads, as
distinguished from "kernel" threads, have been around forever - they
started before kernel multithreading.
George
On Fri, 15 Aug 2003 08:31:44 -0500, ····@rpw3.org (Rob Warnock) wrote:
>I don't know about "best", but I've been using CMUCL with great success
>(sitting between Apache and PostgreSQL), creating a CMUCL "process"
>(green thread, really) per web hit.
He did say it needs to run under windows. I don't believe CMUCL runs
under windows.
I know that Allegro has AllegroServe, which is an open source web
server. You can also you Allegro Lisp free for personal
non-commercial use. I haven't looked at Corman myself.
You sure you can't run it on a Linux Box? With Linux you have a lot
more options on what you can use.
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
> I know that Allegro has AllegroServe, which is an open source web
> server. You can also you Allegro Lisp free for personal
> non-commercial use. I haven't looked at Corman myself.
Yes, Allegro is surely a good choice but i don't want to be hampered
someday with the limitation of the personal use (stack/memory limit).
And since, it's really a personal-app, i can't afford to buy a
license.
> You sure you can't run it on a Linux Box?
> With Linux you have a lot more options on what you can use.
yes, it's true, but i'm actually running under MS and don't plan to
change my computer soon. Surely, later ;)
Doug Tolton <·······@yahoo.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| >I don't know about "best", but I've been using CMUCL with great success...
|
| He did say it needs to run under windows. I don't believe CMUCL
| runs under windows.
+---------------
Oh, he meant << MICROSOFT Windows� >> !!
Silly me. Seeing an all lower-case "windows", I guess I just assumed any
ol' kind of windows, such as X Windows (which CMUCL supports using CLX)...
"Never mind..."
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> I've always wondered: Why do people call within-a-single-O/S-process
> threads (a.k.a. coroutines) "green"?
I got curious about this, so I had a Google session.
According to this article:
http://groups.google.com/groups?selm=3107D7A0.431%40golfweb.com
it started with the threads package used in the Green Project:
http://java.sun.com/people/jag/green/
As to why "green", this article perhaps raises more questions than it
answers:
http://www.sun.com/960201/columns/mark_marc.html
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff <·········@nocrew.org> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > I've always wondered: Why do people call within-a-single-O/S-process
| > threads (a.k.a. coroutines) "green"?
|
| I got curious about this, so I had a Google session.
| According to this article:
| http://groups.google.com/groups?selm=3107D7A0.431%40golfweb.com
| it started with the threads package used in the Green Project:
| http://java.sun.com/people/jag/green/
+---------------
Ahhh, thanks! I was just curious. The first time I ever heard the "green"
nomenclature for within-process threads was when somebody back at SGI
was porting some bits of DCE to Irix, and for simplicity decided to use
"green" threads instead of Irix's "sproc()" [real multiprocessor] threads.
I had just always called them "coroutines" before that.
-Rob
p.s. Lest anyone think that the "it started" above refers to within-process
threads (coroutines) instead of just the "green" nomenclature, process-
local threads are a *LOT* older than Java. BLISS-10 had them in 1970
(explicitly in the language, with the built-in EXCHJ call), and Simula-67
had them implicitly in its object system.
[In fact, there was a cute little macro package for BLISS called "POOMAS",
for "POOr MAn's Simula", that used EXCHJ and BLISS structures to emulate
the basic features of Simula. Much later (1982), Bakul Shah & I re-emulated
POOMAS in C, using setjmp/longjmp to emulate BLISS's EXCHJ (to get coroutines).
We used it to write a discrete event simulator where each "object" was an
infinite-loop coroutine (with timed sleeps and event waits) that defined
its behaviour.]
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Well,
if it doesn't have to be Common Lisp there are several Scheme(which is
a Lisp) implementations that run in the Java VM(they compile to Java
bytecode, but can be interpreted also). The nice thing with these is
that they can also call Java code and vice versa. So you have easy
access to all existing Java libraries, it should also be very easy to
use them in Java webservers like Tomcat, etc...
The two I know of are Kawa and Jscheme(both free software AFAIK).
I would give it a try.
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> The two I know of are Kawa and Jscheme(both free software AFAIK).
Don't forget SISC:
<http://sisc.sourceforge.net/>
Which implements the full R5RS, and is very fast, if interpreted (see
the comparative benchmarks page at :
<http://sisc.sourceforge.net/comp.html>
Raf
thelifter wrote:
> Well,
> if it doesn't have to be Common Lisp there are several Scheme(which is
> a Lisp) implementations that run in the Java VM(they compile to Java
> bytecode, but can be interpreted also). The nice thing with these is
> that they can also call Java code and vice versa. So you have easy
> access to all existing Java libraries, it should also be very easy to
> use them in Java webservers like Tomcat, etc...
>
> The two I know of are Kawa and Jscheme(both free software AFAIK).
Dont forget SISC and Bigloo.
--
Jens Axel S�gaard
On 15-Aug-2003, =?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@jasoegaard.dk>
wrote:
> helifter wrote:
> > Well,
> > if it doesn't have to be Common Lisp there are several Scheme(which is
> > a Lisp) implementations that run in the Java VM(they compile to Java
> > bytecode, but can be interpreted also). The nice thing with these is
> > that they can also call Java code and vice versa. So you have easy
> > access to all existing Java libraries, it should also be very easy to
> > use them in Java webservers like Tomcat, etc...
> >
> > The two I know of are Kawa and Jscheme(both free software AFAIK).
>
> Dont forget SISC and Bigloo.
>
DrScheme - right out of the box. For Windows, Mac, and GNU/lilnux
- Zac
> --
> Jens Axel S�gaard
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Anonymous wrote:
> On 15-Aug-2003, =?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@jasoegaard.dk>
>>helifter wrote:
>>
>>>Well,
>>>if it doesn't have to be Common Lisp there are several Scheme(which is
>>>a Lisp) implementations that run in the Java VM(they compile to Java
>>>bytecode, but can be interpreted also). The nice thing with these is
>>>that they can also call Java code and vice versa. So you have easy
>>>access to all existing Java libraries, it should also be very easy to
>>>use them in Java webservers like Tomcat, etc...
>>>
>>>The two I know of are Kawa and Jscheme(both free software AFAIK).
>>
>>Dont forget SISC and Bigloo.
>>
>
> DrScheme - right out of the box. For Windows, Mac, and GNU/lilnux
That's not implemented using Java technology.
The new version contains some Java languages of various sizes
for teaching, but they are implemented in Scheme, not the other
way around.
--
Jens Axel S�gaard
> - i've seen in some post that yahoo-store was made with CLisp ?? but
> CLisp don't have multi-thread ? how could it work ?
Why are threads always considered to be *so critical* to running a web
server?
While still a beginner when it comes to server/networking issues, I
have written simple web servers (generating dynamic pages) for my own
education in CLisp and I seem to be able to handle multiple users
without difficulty and without hickups.
In my own simple server design, the process functions as follows:
1. A client connects to port 80 with a request
2. The server builds the page and streams the page back through
the port (hopefully with little latency)
3. The socket connection is closed
4. The next client in the queue gets access to the port
Since there is only one port 80, this is a serial process anyway,
isn't it? Or am I missing something fundamental?
Clearly, threads allow certain unrelated benefits such as managing
data for user sessions, but with a language (like LISP) that supports
closures, this seems to be less of an issue. Also clear is that the
latency of the request can be decreased by having a compiled LISP like
CMUCL. But these are minor issues.
What am I missing by not having threads?
Can somebody explain?
"Conrad Barski" <·····················@yahoo.com> wrote in message
·································@posting.google.com...
> > - i've seen in some post that yahoo-store was made with CLisp ?? but
> > CLisp don't have multi-thread ? how could it work ?
>
> Why are threads always considered to be *so critical* to running a web
> server?
>
> While still a beginner when it comes to server/networking issues, I
> have written simple web servers (generating dynamic pages) for my own
> education in CLisp and I seem to be able to handle multiple users
> without difficulty and without hickups.
>
> In my own simple server design, the process functions as follows:
> 1. A client connects to port 80 with a request
> 2. The server builds the page and streams the page back through
> the port (hopefully with little latency)
> 3. The socket connection is closed
> 4. The next client in the queue gets access to the port
>
> Since there is only one port 80, this is a serial process anyway,
> isn't it? Or am I missing something fundamental?
You are missing some issues which may delay the generation
of the page.
1) The page may be proxied, and have to be gotten from another
server
2) You are validating a Credit Card transaction with a credit
card server
3) You do a query to an SQL database to build the page
The (hopefully with little latency) is the problem. Especially if you
are doing a credit card validation/transaction, you can be talking
30 seconds. Also a SQL query can take an indeterminate amount
of time. All this time waiting to build the page could be used to
service another request and get things going with another user.
Granted, most web-sites do not have this much traffic, but
also a user may walk away from your site if you do not
service a request within 10 seconds.
I would be my guess that Yahoo-Store probably uses the select()
function to service multiple connections at once and might
have some state/event/action model to complex page generation.
Wade
"Wade Humeniuk" <····@nospam.nowhere> wrote in message news:<····················@news2.telusplanet.net>...
> "Conrad Barski" <·····················@yahoo.com> wrote in message
> ·································@posting.google.com...
> > > - i've seen in some post that yahoo-store was made with CLisp ?? but
> > > CLisp don't have multi-thread ? how could it work ?
[.....]
> I would be my guess that Yahoo-Store probably uses the select()
> function to service multiple connections at once and might
> have some state/event/action model to complex page generation.
>
> Wade
wrong tense, I am afraid. Yahoo-Store is C++ now.
-km
According to Wade Humeniuk <····@nospam.nowhere>:
> I would be my guess that Yahoo-Store probably uses the select()
> function to service multiple connections at once and might
> have some state/event/action model to complex page generation.
I read that, paraphrased, "each user got his own image".
Fork/exec CGI thingy, methinks.
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
> What am I missing by not having threads?
> Can somebody explain?
In my case, i want to build a personal "assistant" : some of the
interactions will be browser-based ( so i need to listen to a port ).
Interactions not already browser-based will be text-based through
Emacs. The system will also use an internal tasks-agenda to evolve
itself in background. So the system will need multi-tasking.
Even in a normal context of a simple web-based server, i need
multi-thread just to modify/inspect the app without interrupting the
server. It's a tremendous advantage over others web-app language. I
don't want to be locked listening the input port.
Just for info, the "assistant" will be aimed at using knowledge about
programming...
On 15-Aug-2003, ·····················@yahoo.com (Conrad Barski) wrote:
>
> Why are threads always considered to be *so critical* to running a web
> server?
>
> While still a beginner when it comes to server/networking issues, I
> have written simple web servers (generating dynamic pages) for my own
> education in CLisp and I seem to be able to handle multiple users
> without difficulty and without hickups.
>
Look up c.l.l on google, on this issue with clisp. Apparently, it can
handle a few numbers of users at the same time.
Graham duplicated a clisp image.
- Zac
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
·····················@yahoo.com (Conrad Barski) writes:
> Why are threads always considered to be *so critical* to running a web
> server?
> 2. The server builds the page and streams the page back through
> the port (hopefully with little latency)
Not all requests are possible to answer quickly. If one user requests a
page that takes some time to build, then (without threads) all other users are
denied service until the first has completed.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If you pick up a starving dog and make him prosperous, he will not bite you.
This is the principal difference between a man and a dog.
-- Mark Twain
From: Peter Seibel
Subject: Re: free cl implementation for web-based app ?
Date:
Message-ID: <m3bruppbmc.fsf@javamonkey.com>
·····················@yahoo.com (Conrad Barski) writes:
> > - i've seen in some post that yahoo-store was made with CLisp ?? but
> > CLisp don't have multi-thread ? how could it work ?
>
> Why are threads always considered to be *so critical* to running a web
> server?
>
> While still a beginner when it comes to server/networking issues, I
> have written simple web servers (generating dynamic pages) for my own
> education in CLisp and I seem to be able to handle multiple users
> without difficulty and without hickups.
>
> In my own simple server design, the process functions as follows:
> 1. A client connects to port 80 with a request
> 2. The server builds the page and streams the page back through
> the port (hopefully with little latency)
> 3. The socket connection is closed
> 4. The next client in the queue gets access to the port
>
> Since there is only one port 80, this is a serial process anyway,
> isn't it? Or am I missing something fundamental?
You are missing something. While it is true that accepting connections
is generally single-threaded, once a connection has been accepted the
actual work of reading from and writing to that connection, not to
mention all the other work that goes into generating the response, can
be done in a separate thread. (While there's only one port 80, as you
say, a socket connection is determined by *four* numbers, the IP
addresses of the server and the client, the port on the server, *and*
a port on the client, which is generally chosen randomly. Thus the
server can have multiple sockets open to different clients at the same
time. In a multithreaded server, the thread that listens for
connections, makes the new socket and then hands it off to another
thread to handle.
Which is especially good because any one of those requests is likely
to spend a lot of time blocked on i/o--waiting for data to read from
the socket, waiting for data from the disk, waiting for the TCP
buffers to empty out on writes. And if you have to talk to a database
to satisify the request, that's more i/o latency. And all of that time
your computer would be sitting there doing nothing if there weren't
other threads handling other requests that could use the CPU.
Threads[1] are required for high-performance systems in order to deal
with blocking operations. If any of the things you need to do can
block, a single-threaded system will bottleneck on those operations.
If you don't want to deal with threads, you need asynchronous APIs to
all potentially blocking operations (making them not blocking.) But
the tide of history seems have swung toward synchronous APIs + threads
and away from asynchronous programming (except in GUIs).
-Peter
[1] Or separate processes. Which is what I think Graham did with
Viaweb--one CLISP process per user. Which is probably fine for web
servers since there is no need to share data between different users.
This is also what most C-based web servers written did for a long
time--Apache, as I understand it, had some clever way of passing off
the sockets to prespawned child processes to handle while the main
process went back to accepting connections. There's a reason threads
are often called "lightweight processes".
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Threads[1] are required for high-performance systems in order to deal
> with blocking operations. If any of the things you need to do can
> block, a single-threaded system will bottleneck on those operations.
> If you don't want to deal with threads, you need asynchronous APIs to
> all potentially blocking operations (making them not blocking.) But
> the tide of history seems have swung toward synchronous APIs + threads
> and away from asynchronous programming (except in GUIs).
Up to a point, at least. Dan Kegel's oft-referenced C10K paper
suggests that tide of history notwithstanding, if you want serious
high-performance you're still better off with non-blocking operations.
http://www.kegel.com/c10k.html
Which in a sense is trivially obvious. The time taken to do a context
switch is a function of the amount of context that needs switching: if
all that you need to swap at each scheduling opportunity is the file
descriptors to copy to and from, and the file offset to start at,
that's obviously going to be faster than using a separate thread with
its own stack, register contents, fpu settings ... for each file
you're serving. As you say, though, it's also going to be
correspondingly more painful, of course - why jump throught these
hoops unless you have to?
The real reason though is NIH syndrome. As ianb pointed out,
integrating random Python code with Twisted is hard, since it might
block. This forces us to rewrite every potential piece of code we
might need, from scratch, to fit our needs.
-- Itamar Shtull-Trauring, out of context, on the Twisted
Python framework : http://www.advogato.org/article/668.html#15
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
> - i've seen in some post that yahoo-store was made with CLisp ?? but
> CLisp don't have multi-thread ? how could it work ?
I think yahoo-store - the clisp version - uses a clisp-image for
each user. But this is only the process, which creates and changes
new pages. The publication-process then generates static html-
pages, which will be statically served.
best regards
jens himmelreich