I do not know Lisp, so the answer to these questions may be obvious,
but here goes...
Does Common Lisp support threading? If not, isn't that a serious
limitation to what could be developed using Lisp? Or is there
something "threadish" about Lisp that makes this a non-issue?
Obviously most server software is heavily dependent on threading.
Even simple software, like web servers, require threading. Can these
things be written in Lisp?
Thanks for your answers!
Darren wrote:
> I do not know Lisp, so the answer to these questions may be obvious,
> but here goes...
>
> Does Common Lisp support threading?
No; that is, thread support is not part of the language definition.
However, several implementations support 'green' threads (often called
'multiprocessing' in the Lisp world), a couple support native threads,
and a couple more have yet another method ('serve-event') of supporting
interleaved threads of control.
is someone going to create a clrfi http://clrfi.alu.org/
about this issue?
-jim
mikel wrote:
> Darren wrote:
>
>> I do not know Lisp, so the answer to these questions may be obvious,
>> but here goes...
>>
>> Does Common Lisp support threading?
>
>
> No; that is, thread support is not part of the language definition.
> However, several implementations support 'green' threads (often called
> 'multiprocessing' in the Lisp world), a couple support native threads,
> and a couple more have yet another method ('serve-event') of supporting
> interleaved threads of control.
·········@hotmail.com (Darren) wrote:
> Obviously most server software is heavily dependent on threading.
> Even simple software, like web servers, require threading.
no, you can write servers without threading, in Unix if you use SELECT. As
far as I know SELECT is not defined in Common Lisp, but I think most
implementations provide it.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
·········@hotmail.com (Darren) writes:
> Does Common Lisp support threading?
The use of threads in Lisp dates from the complete operating
systems that written entirely in Lisp in the 1970s (long before
the more popular "modern" languages and systems had them).
However, the ANSI language definition was trying to be very OS-agnostic,
and did not adopt into the standard any way of doing multiprocessing,
networking, and many other things. However, each Common Lisp implementation,
back then and today, does have these features, and there are also open source
compatability libraries. This means that you can access these features in
your Common Lisp program by coding to either your vendor's proprietary API,
or portably using the least-common-denominator compatability APIs.
+ ·········@hotmail.com (Darren):
| I do not know Lisp, so the answer to these questions may be obvious,
| but here goes...
|
| Does Common Lisp support threading?
No, Common Lisp the standard does not support threading.
Yes, many Common Lisp implementations support threading.
I'll leave the rest of your questions to people with more experience
than I have in writing server software. But even I know that servers
can be written in Lisp, both with and without using threading.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
"Darren" <·········@hotmail.com> wrote
>
> Does Common Lisp support threading? If not, isn't that a serious
> limitation to what could be developed using Lisp? Or is there
> something "threadish" about Lisp that makes this a non-issue?
>
> Obviously most server software is heavily dependent on threading.
No. Apache, by far the most used web server on the planet use a pre-fork
model and not threading. (though Apache 2 can use threading)
> Even simple software, like web servers, require threading. Can these
> things be written in Lisp?
Of course they can. With or without threads.
Have a look at http://www.cliki.net/Web that should be enough for you. ;-)
Marc
"Marc Battyani" <·············@fractalconcept.com> wrote in message news:<··········@library2.airnews.net>...
> "Darren" <·········@hotmail.com> wrote
> >
> > Does Common Lisp support threading? If not, isn't that a serious
> > limitation to what could be developed using Lisp? Or is there
> > something "threadish" about Lisp that makes this a non-issue?
> >
> > Obviously most server software is heavily dependent on threading.
>
> No. Apache, by far the most used web server on the planet use a pre-fork
> model and not threading. (though Apache 2 can use threading)
I agree pre-forking works great in many cases, such as web servers
because they are request-response based, but it makes things such as
sharing resources across connections difficult or at least alot more
complicated. Process spawning also tends to be alot slower, which I
think is why Apache 2 introduced threads. For other problems, mostly
asynchronus scenarios, it simply won't work. (well, you could probably
make an ugly hack, but eww).
It sounds like threading really needs to be added to the standard,
seeing as many implementations (pointed out above) have it in anyways.
Glad to hear there are ones out there though. Thanks for the
answers.
·········@hotmail.com (Darren) writes:
> > No. Apache, by far the most used web server on the planet use a pre-fork
> > model and not threading. (though Apache 2 can use threading)
>
> I agree pre-forking works great in many cases, such as web servers
> because they are request-response based, but it makes things such as
> sharing resources across connections difficult or at least alot more
> complicated.
Not in C when you use fork+mmap.
Unfortunately mmap is hard in lisp.
An implementation could provide an easy interface to mmap though.
Anybody wants to write CLRFI for mmap?
> Process spawning also tends to be alot slower, which I
> think is why Apache 2 introduced threads. For other problems, mostly
> asynchronus scenarios, it simply won't work. (well, you could probably
> make an ugly hack, but eww).
>
> It sounds like threading really needs to be added to the standard,
> seeing as many implementations (pointed out above) have it in anyways.
> Glad to hear there are ones out there though. Thanks for the
> answers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
·········@hotmail.com (Darren) wrote in message news:<···························@posting.google.com>...
> I do not know Lisp, so the answer to these questions may be obvious,
> but here goes...
>
> Does Common Lisp support threading? If not, isn't that a serious
> limitation to what could be developed using Lisp? Or is there
> something "threadish" about Lisp that makes this a non-issue?
>
> Obviously most server software is heavily dependent on threading.
> Even simple software, like web servers, require threading.
If you want to write a serious, high-performance server, it takes more
than threads. You have to consider all the tools of the given platform
that you are targetting: asynchronous file I/O, I/O completion ports,
and such.
The threading support you find in languages that have
platform-independent threading is woefully inadequate for
high-performance computing, so much so that it's almost not worth
having.
A naive use of threads to write a server can be worse than a
single-threaded event loop that dispatches handlers.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> ·········@hotmail.com (Darren) wrote in message news:<···························@posting.google.com>...
> > I do not know Lisp, so the answer to these questions may be obvious,
> > but here goes...
> >
> > Does Common Lisp support threading? If not, isn't that a serious
> > limitation to what could be developed using Lisp? Or is there
> > something "threadish" about Lisp that makes this a non-issue?
> >
> > Obviously most server software is heavily dependent on threading.
> > Even simple software, like web servers, require threading.
>
> If you want to write a serious, high-performance server, it takes more
> than threads. You have to consider all the tools of the given platform
> that you are targetting: asynchronous file I/O, I/O completion ports,
> and such.
>
> The threading support you find in languages that have
> platform-independent threading is woefully inadequate for
> high-performance computing, so much so that it's almost not worth
> having.
>
> A naive use of threads to write a server can be worse than a
> single-threaded event loop that dispatches handlers.
Writing I/O completion ports is done with threads, and was part of the
reason for my question. Unless Lisp implementations have an API that
handles them for you. Which would be nice.
I would also like to make other pools though, for things such as
database connections, or other external, unmanaged services. For
exmample, if I was to connect to an SMSC or any connection limited
device, I would want an outbound shared connection pool to manage it.
I might also need those pools threads to utilize an asynchronus
response handler implemented by another pool for handling responses.
For synchronus handling of an unmanaged asynch reousrce, if the
request and response operate on different ports (like in a SMSC), it
could be:
Connection(n)-> Port_Pool(y=<n)-> SMSC_pool(x=<X)-> SMSC(X)->
SMSC_Response_Handler_Pool(x)-> Port_Pool(y)-> Connection(n)
Of course this would limit the first pool and connections would have
to be refused if x were exceeded by y before being released by the
response handler. But for a QoS based system you might want to reject
the inbound connections based on a policy of this state. The
Port_Pool might just be a reserve for low priority connections or ones
that can't handle an asynch response. There could even be more pools
to meet the different QoS policies based on the connection origin and
improviso states incurred from load/latency/errors and contract with
the external resource.
Anyways, threads are important to me and the thread question has been
answered with a resounding yes. So this can be done in Lisp.
Darren <·········@hotmail.com> wrote:
> I do not know Lisp, so the answer to these questions may be obvious,
> but here goes...
>
> Does Common Lisp support threading? If not, isn't that a serious
> limitation to what could be developed using Lisp? Or is there
> something "threadish" about Lisp that makes this a non-issue?
>
> Obviously most server software is heavily dependent on threading.
Not at all.
> Even simple software, like web servers, require threading.
No, where did you get this wrong and foolish idea? Plenty of servers
have been written without any threading at all. In UNIX, simultaneously
handling multiple connections is accomplished with the select(2) system
call. Worked pretty well for 2 decades and still does.
> Can these things be written in Lisp?
They can, they have been and they are.
While threading is not part of the Common Lisp standard, most
implementations offer something along those lines. Some also make the
UNIX select(2) call available.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
>>>>> "AS" == Alexander Schreiber <···@usenet.thangorodrim.de> writes:
AS> ... Plenty of
AS> servers have been written without any threading at all. In
AS> UNIX, simultaneously handling multiple connections is
AS> accomplished with the select(2) system call. Worked pretty
AS> well for 2 decades and still does.[...]
Agreed.
For better alternatives to select (that scale up better) see
http://www.kegel.com/c10k.html
Also in the http context, thttpd
http://www.acme.com/software/thttpd/
is a simple high performance web server that serves up content
w/o [pre]forking or spinning up threads.
cheers,
BM
Alexander Schreiber <···@usenet.thangorodrim.de> wrote in message news:<··················@mordor.angband.thangorodrim.de>...
> Darren <·········@hotmail.com> wrote:
> > I do not know Lisp, so the answer to these questions may be obvious,
> > but here goes...
> >
> > Does Common Lisp support threading? If not, isn't that a serious
> > limitation to what could be developed using Lisp? Or is there
> > something "threadish" about Lisp that makes this a non-issue?
> >
> > Obviously most server software is heavily dependent on threading.
>
> Not at all.
>
> > Even simple software, like web servers, require threading.
>
> No, where did you get this wrong and foolish idea? Plenty of servers
> have been written without any threading at all. In UNIX, simultaneously
> handling multiple connections is accomplished with the select(2) system
> call. Worked pretty well for 2 decades and still does.
>
> > Can these things be written in Lisp?
>
> They can, they have been and they are.
>
> While threading is not part of the Common Lisp standard, most
> implementations offer something along those lines. Some also make the
> UNIX select(2) call available.
>
> Regards,
> Alex.
Sorry, saying "require threads" was wrong. However, replace threads
with processes and the same holds true.
select(2) combined with multiple processes might as well be considered
the same as threads, at least on Unix...sort of. However, there are
definetly times where threaded connection handling is better.
Multi-process/multi-threads scales better, then multi-process alone,
if the OS is capable of doing it. On some OS's multi-threaded works
better then multi-process. That's the same reason Apache moved to
that model.
That said, we are still talking about web servers, but that isn't what
I was really concerned about. I shouldn't have mentioned them at all.
Web servers are at the low-end of server software in terms of
complexity of processing. They are turbo-charged, byte pushing
monsters, but their brains are small. Lots of other server apps
require bigger brains. When the processing for a request requires
heavy concurrency, obviously threads will make life much easier.
I was just curious about the limits of Lisp. From the answers given,
as long as I use a Lisp implementation with select and thread support,
then there is nothing to worry about.
- Darren
·········@hotmail.com (Darren) wrote in message news:<···························@posting.google.com>...
[...]
> I was just curious about the limits of Lisp. From the answers given,
> as long as I use a Lisp implementation with select and thread support,
> then there is nothing to worry about.
I'd take a look at Flez [http://lisp-p.org/flez/] by Gene Michael
Stover:
"It's a library for writing programs that are based on an event-driven
architecture. Flez is written in Common Lisp. Programs which use it
will probably be written in Common Lisp. Flez should be appropriate
for use in simulations & games."
Stover used it, with clisp, a relatively slow bytecode implementation,
to build a simple server for multiple clients
(http://www.lisp-p.org/tcpmux/node1.html). There is an overview of the
performance at http://www.lisp-p.org/tcpmux/node10.html. The
conclusion seems to be that the system scales better than expected,
but using read/write -byte is very expensive. Stover believes that
buffering the streams (which he was unable to do in clisp - the fault
still has to be assigned :) or possibly using FFIs to unix read/write
could help with that.
So, even without select or thread support, multiple clients are
possible. Moreover, it seems that this application is IO-bound, which
(i guess) isn't so bad if you want to do more than serving static
html.
Paul Khuong