I'm evaluating different ideas for my thesis, but it definately has
to be something related
with SMP and green threads. After playing with cl-muproc , termite and
erlang i thought of writing scheme like language & implementation with
built in support for SMP and green threads, but i realized it'll be
useless for anybody else beside me, so maybe implementing SMP & green
threads in ECL or SBCL (i avoid CLisp because of GPL) could make some
difference. The problem is that common lisp is a huge beast for
implementing, especially compared with scheme so i would like to hear
some thoughts about the estimation of potential amount of work to do.
From: Matthew D Swank
Subject: Re: implementing SMP & Gambit like threads in Common Lisp implementation
Date:
Message-ID: <pan.2007.04.18.13.00.19.425794@c.net>
On Wed, 18 Apr 2007 02:48:58 -0700, nicola.tivoli wrote:
> I'm evaluating different ideas for my thesis, but it definately has
> to be something related
> with SMP and green threads. After playing with cl-muproc , termite and
> erlang i thought of writing scheme like language & implementation with
> built in support for SMP and green threads, but i realized it'll be
> useless for anybody else beside me, so maybe implementing SMP & green
> threads in ECL or SBCL (i avoid CLisp because of GPL) could make some
> difference. The problem is that common lisp is a huge beast for
> implementing, especially compared with scheme so i would like to hear
> some thoughts about the estimation of potential amount of work to do.
Wow, someone actually excited about doing green threads in Common Lisp.
Light weight concurrency doesn't seem to get much traction in the CL
world. CL implementors are understandably more concerned with providing
basic support for machine concurrency, and the only existing green threads
implementation I can think of (CMUCL) isn't terribly robust.
One stumbling block in providing better concurrency abstractions in Common
Lisp stems from its runtime flexibility. Unlike Erlang or Termite, at
runtime Common Lisp has a large body of shared state that can be
explicitly mutated.
Anyway, I don't want to discourage you. I love the idea of the project.
Though Common Lisp is at its heart a practical language, something besides
low level access to OS threads is needed.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
On 18 abr, 10:48, ·············@gmail.com wrote:
> I'm evaluating different ideas for my thesis, but it definately has
> to be something related
> with SMP and green threads. After playing with cl-muproc , termite and
> erlang i thought of writing scheme like language & implementation with
> built in support for SMP and green threads, but i realized it'll be
> useless for anybody else beside me, so maybe implementing SMP & green
> threads in ECLor SBCL (i avoid CLisp because of GPL) could make some
> difference.
ECL already has some kind of support for threads, so it would be an
easier start. There are a number of things to be improved and which
could be interesting. For instance, handling signals in threads and
between threads; improving garbage collection which is currently based
on the Boehm-Weiser library; a more efficient design for special
variables (currently it is expensive in multithreaded ECL); better
isolation between threads perhaps with more Erlang-like processes;
userland threads (they used to be in there)... I am the maintainer of
ECL and thus my opinion is very much biased, but ECL is a rather
modular code and it is not too difficult to start hacking it.
Juanjo
In article <························@n59g2000hsh.googlegroups.com>,
·············@gmail.com wrote:
> I'm evaluating different ideas for my thesis, but it definately has
> to be something related
> with SMP and green threads. After playing with cl-muproc , termite and
> erlang i thought of writing scheme like language & implementation with
> built in support for SMP and green threads, but i realized it'll be
> useless for anybody else beside me, so maybe implementing SMP & green
> threads in ECL or SBCL (i avoid CLisp because of GPL) could make some
> difference. The problem is that common lisp is a huge beast for
> implementing, especially compared with scheme so i would like to hear
> some thoughts about the estimation of potential amount of work to do.
Check out OpenMCL also. The number of platforms it runs
on is rising.
http://www.openmcl.org/
http://www.openmcl.org/Doc/index.html#Programming-with-Threads
OpenMCL supports native threads and SMP. OpenMCL is
not *that* big and it recompiles itself on a Core 2 Duo
in about 40 seconds (which is totally cool if you ask me).
--
http://lispm.dyndns.org
(message (Hello ··············@gmail.com)
(you :wrote :on '(18 Apr 2007 02:48:58 -0700))
(
nt> with SMP and green threads. After playing with cl-muproc , termite and
nt> erlang i thought of writing scheme like language & implementation with
nt> built in support for SMP and green threads, but i realized it'll be
nt> useless for anybody else beside me, so maybe implementing SMP & green
nt> threads in ECL or SBCL
but they already have some kind of threads, especially SBCL.
nt> (i avoid CLisp because of GPL)
clisp doesn't, and there are lots of people who'd like it to have it.
i'm afraid threads implementation have very little scientific value, at
least for last 20 years or so. or it's ok for thesis to be something that's
already has dozens existing implementations?
if you'd like something in that field, i think you can work on concurrent
GC, for SBCL, for example. or implement some high-level multiprocessing
primitives -- for example, queues, preferably portable for different
implementations. also futures would be cool, but it's not easy at all :)
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")