Hi,
I am considering using SERVE-EVENT to provide multitasking in my
application. I read the CMUCL user manual and I am looking for more
information. Could you please recommend one?
Thanks in advance.
--
Kamen TOMOV
Kamen TOMOV <·····@evrocom.net> writes:
> Hi,
>
> I am considering using SERVE-EVENT to provide multitasking in my
> application. I read the CMUCL user manual and I am looking for more
> information. Could you please recommend one?
If you're using an X86 version of CMUCL, you might as well use the
multiprocessing package, which is a convenient layer over the
serve-event stuff.
If you really want to use serve-event, take a look at the feebs code
in the CMUCL source distribution: src/contrib/games/feebs.
--
Fred Gilham ······@csl.sri.com
In Nashville there ain't no money above the third fret. -- Jay Carlson
On Wed, Apr 05 2006, Fred Gilham wrote:
> Kamen TOMOV <·····@evrocom.net> writes:
>
>> Hi,
>>
>> I am considering using SERVE-EVENT to provide multitasking in my
>> application. I read the CMUCL user manual and I am looking for more
>> information. Could you please recommend one?
>
> If you're using an X86 version of CMUCL, you might as well use the
> multiprocessing package, which is a convenient layer over the
> serve-event stuff.
Thanks.
Could you tell me what is the name of the package if there is any
documentation about it?
> If you really want to use serve-event, take a look at the feebs code
> in the CMUCL source distribution: src/contrib/games/feebs.
I'll look it up.
--
Kamen TOMOV
BTW, if you look at the feebs code, you need to add the following to
make it compile:
(defpackage "FEEBS"
(:use "COMMON-LISP")
(:shadow position) <<<<<< Add this.
--
Fred Gilham ······@csl.sri.com
Perhaps the greatest damage the American system of education has done
to its children is to teach them that their opinions are relevant
simply because they are their opinions.
>>>>> "Kamen" == Kamen TOMOV <·····@evrocom.net> writes:
Kamen> Hi,
Kamen> I am considering using SERVE-EVENT to provide multitasking in my
Kamen> application. I read the CMUCL user manual and I am looking for more
Kamen> information. Could you please recommend one?
I think that's all the documentation you will find on serve-event,
other than reading code that uses serve-event. CMUCL also has a
multiprocessing capability (green threads) but the only documentation
for that is in the code itself. It was modeled after some other
multiprocessing scheme, but I can't remember what.
If you don't need to use CMUCL or serve-event, you might consider
using SBCL which has OS-level threads on some platforms. Other free
lisps might have threads too, but I don't know. Allegro and Lispworks
probably have threads too.
Ray
On Wed, 05 Apr 2006 11:36:26 -0400, Raymond Toy wrote:
> you might consider using SBCL which has OS-level threads on some
> platforms.
SBCL also has SERVE-EVENT available in the SB-SYS package.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
On Wed, Apr 05 2006, Raymond Toy wrote:
>
> I think that's all the documentation you will find on serve-event,
> other than reading code that uses serve-event.
Thanks.
> CMUCL also has a multiprocessing capability (green threads) but the
> only documentation for that is in the code itself. It was modeled
> after some other multiprocessing scheme, but I can't remember what.
What is the meaning of "green threads"? How do they differ with the
general understanding of the threaded model?
--
Kamen TOMOV
Kamen TOMOV wrote:
> What is the meaning of "green threads"? How do they differ with the
> general understanding of the threaded model?
Green threads typically means threads implemented entirely in
userspace. Native threads (red threads I suppose, though I haven't
heard that term much) means threads implemented with OS support. On
pretty much any Unix-like system this means that green threads will all
live inside one OS-level thread/LWP, and this in turn means that all
the threads will be scheduled on a single processor (core is perhaps a
more correct term now). So on a multi core machine (um, I don't meen
that those multiple cores have to be in the same socket...) such
systems will not be able to make very good use of the available
parallelism. But they are much easier to implement, especially in
terms of GC and so on.
--tim
On Wed, 05 Apr 2006 12:23:37 -0700, Tim Bradshaw wrote:
> such systems will not be able to make very good use of the available
> parallelism. But they are much easier to implement
Green threads (usually) allow faster context switching than OS threads.
Also, it's easier to use large numbers of green threads. There are
problems using synchronous I/O and green threads, but a hybrid system
seems desirable (see Robert Pike's paper "Rio: Design of a Concurrent
Window System" http://herpolhode.com/rob/lec5.pdf).
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
>
> Green threads (usually) allow faster context switching than OS threads.
Well, that's very dependent on many factors. But in the particular
case of a machine with more than one core (which will be almost all new
machines in a relatively short time), there may not be any context
switches for native threads - it's hard to beat that.
> Also, it's easier to use large numbers of green threads. There are
> problems using synchronous I/O and green threads, but a hybrid system
> seems desirable (see Robert Pike's paper "Rio: Design of a Concurrent
> Window System" http://herpolhode.com/rob/lec5.pdf).
Solaris has gone through this - pre 9 (but post something earlier)
there were two models - an MxN one where there were M userland threads
scheduled on top of (a smaller number) N LWPs. They've now moved to a
1-1 model where there each thread corresponds to an LWP - I presume
because this turned out to be faster (it's certainly simpler). Of
course their target market is largely muticore machines. But as I said
above: soon that will be all machines.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> Green threads typically means threads implemented entirely in
> userspace. Native threads (red threads I suppose, though I haven't
> heard that term much) means threads implemented with OS support.
Why would native threads be red threads?
Lars Brinkhoff wrote:
> Why would native threads be red threads?
Because green and red are often used as colours for complementary
things - safe (green) vs dangerous (red), left (red) vs right (green)
and so on.
--tim
On Thu, 06 Apr 2006 12:40:47 -0700, Tim Bradshaw wrote:
> Lars Brinkhoff wrote:
>
>> Why would native threads be red threads?
>
> Because green and red are often used as colours for complementary
> things - safe (green) vs dangerous (red), left (red) vs right (green)
> and so on.
The story I had heard was that when Java was being implemented, the people
doing it happened to use a green whiteboard marker to represent non-native
threads.
Google doesn't seem to be able to find this story for me though. The only
thing I can find offers an alternate explanation:
http://www.macromedia.com/devnet/server_archive/articles/jrun3_performance_and_scalability_pt2.html
(search for "green threads" within that page).
Cheers,
Bill.
Kamen TOMOV wrote:
> What is the meaning of "green threads"? How do they differ with the
> general understanding of the threaded model?
Green threads are simulated threads, see e.g. for Java:
http://mindprod.com/jgloss/thread.html
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Raymond Toy <···········@ericsson.com> wrote:
>>>>>> "Kamen" == Kamen TOMOV <·····@evrocom.net> writes:
> Kamen> Hi,
> Kamen> I am considering using SERVE-EVENT to provide multitasking in my
> Kamen> application. I read the CMUCL user manual and I am looking for more
> Kamen> information. Could you please recommend one?
>
> I think that's all the documentation you will find on serve-event,
> other than reading code that uses serve-event. CMUCL also has a
> multiprocessing capability (green threads) but the only documentation
> for that is in the code itself. It was modeled after some other
> multiprocessing scheme, but I can't remember what.
There is a broken link on
<http://www.cons.org/cmucl/platforms.html> which pointed to the
documentation. I've searched for the real page (and reported it
to the webmaster a year ago):
http://www.mikemac.com/mikemac/clim/clim-sys.html
Here is some more:
http://www.trakt7.net/cmucl%20and%20multiprocessing
On Thu, Apr 06 2006, Stefan Scholl wrote:
> ...
> http://www.trakt7.net/cmucl%20and%20multiprocessing
Well, that's a great place to start. Thank you.
Thanks to everybody!
--
Kamen TOMOV
Kamen TOMOV <·····@evrocom.net> writes:
> I am considering using SERVE-EVENT to provide multitasking in my
> application. I read the CMUCL user manual and I am looking for more
> information. Could you please recommend one?
Possibly you might be interested in a talk Eric Marsden gave at the
Libre Software Meeting in 2004. His notes are available as part of
the lightning talks summary, at
<http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/lightning/lightning.html#htoc6>.
Christophe
On Wed, Apr 05 2006, Christophe Rhodes wrote:
> Possibly you might be interested in a talk Eric Marsden gave at the
> Libre Software Meeting in 2004. His notes are available as part of
> the lightning talks summary, at
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/lightning/lightning.html#htoc6>.
Thanks!
--
Kamen TOMOV
I run a server that works in a multi-threaded mode under CMUCL. As far
as I understand MP (multiprocessing) in CMUCL runs on top of
SERVE-EVENT mechanism. I expect to have long file-copying operations
so in order to keep my server responsive I need to make such
operations run in the background.
So my question is - is it OK to mess with the SERVE-EVENT functions
such add-fd-handler, remove-fd-handler etcetera while multiprocessing
is being run under CMUCL? What is the proper way to do it?
Thanks in advance.
--
Kamen TOMOV