Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can you multi-thread in LISP

179 views
Skip to first unread message

David E. Hallman

unread,
Apr 5, 1998, 4:00:00 AM4/5/98
to

Does CLOS support the creation of multiple thread's ? I'm used to
doing this in NT/UNIX in C++. Any help would be appreciated...

Hartmann Schaffer

unread,
Apr 5, 1998, 4:00:00 AM4/5/98
to dhal...@erols.com

David E. Hallman wrote:
>
> Does CLOS support the creation of multiple thread's ? I'm used to
> doing this in NT/UNIX in C++. Any help would be appreciated...

Multithreading is not part of the CL standard, but many implementations
seem to support it. From what I understand there is work in progress to
include it in the next major release of CMUCL.

--

Hartmann Schaffer
Guelph, Ontario, Canada
scha...@netcom.ca (hs)

McHugh's News Server

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

As well as in the forthcoming Franz Allegro CL 5.0.


Hartmann Schaffer wrote in message <35281008...@netcom.ca>...

Erik Naggum

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

* somebody anonymous using McHugh's News Server, probably Robert Manjoney

| As well as in the forthcoming Franz Allegro CL 5.0.

huh? multithreading has been an integral part of Allegro Common Lisp for
many, many years, going all the way back to the Franz Lisp I used in 1987
or whenever it was, and it probably had multithreading since day one.

if you mean Allegro CL specifically for Windows, please say so. I have
never been a fan of Allegro for Windows; it's a radically different and
much inferior product in all interesting ways to Allegro CL for Unix, the
Real Thing. however, if you want multithreading for NT, check out ACL
4.3.2. if you want to see that it actually works on an Intel that is not
drugged down with Windoze, get the free ACL 4.3 for Linux. all the other
Unix releases are at 4.3.1.

I'm building a moderately-sized Lisp application that wouldn't even exist
if it were not for the multithreading in Allegro CL for Unix. also, I
couldn't use the Emacs interface to Allegro CL as efficiently as I am
without the multithreading in Allegro CL for Unix. I'm compiling,
evaluting long-running functions, completing symbols and requesting
arglists and documentation, as well as doing note-book style interactions
in the Lisp listener all at the same time. this is why I couldn't live
with CMUCL after I started to use Allegro CL.

while multithreading and all the cool stuff may be quite the novelty
under Bill Gates' dysfunctional regime, it has actually existed and been
taken for granted elsewhere for several decades. It's saddening that
people actually believe that something so old is in any way new or worthy
of interest. the world should have shouted "god damn it, Bill, what the
heck _took_ you so long!?" instead of embracing his belated junkware.

#:Erik
--
religious cult update in light of new scientific discoveries:
"when we cannot go to the comet, the comet must come to us."

Lawrence Troxler

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

Erik Naggum <cle...@naggum.no> wrote:
: * somebody anonymous using McHugh's News Server, probably Robert Manjoney

: | As well as in the forthcoming Franz Allegro CL 5.0.

: huh? multithreading has been an integral part of Allegro Common Lisp for
: many, many years, going all the way back to the Franz Lisp I used in 1987
: or whenever it was, and it probably had multithreading since day one.

PMFJI, but I was under the impression that Allegro's multiple "threads" of
Lisp execution take place under co-operative multitasking, under a singl
CPU thread. Maybe I'm mistaken?

Larry


--
-- Larry Troxler -- l...@westnet.com -- Patterson, NY USA --

Don Geddis

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

On 6 Apr 1998 18:05:38 GMT, Lawrence Troxler <l...@westnet.com> wrote:
> I was under the impression that Allegro's multiple "threads" of
> Lisp execution take place under co-operative multitasking, under a singl
> CPU thread. Maybe I'm mistaken?

Franz's ACL threads do take place under a single unix "process". ACL has
it's own scheduler, and does pre-emptive (not "co-operative") multitasking
for all internal Lisp threads.

I've heard rumors that the delay in ACL 5.0 is due to Franz interfacing the
threads package more directly with the native operating system processes. This
is apparently difficult, especially under Windows NT.

-- Don
--
Don Geddis ged...@tesserae.com
Tesserae Information Systems, Inc. http://tesserae.com
50 West San Fernando Street, Suite 700 Phone: (408) 938-6037
San Jose, CA 95113 Fax: (408) 938-6098

Erik Naggum

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

* Lawrence Troxler
| PMFJI, but I was under the impression that Allegro's multiple "threads" of
| Lisp execution take place under co-operative multitasking, under a single

| CPU thread. Maybe I'm mistaken?

no.

why do you quote _thread_ just because Allegro doesn't use one particular
implementation of a well-known technology with lots of very different
implementations? OS-level "threads" are mainly useful to C programmers,
who can get nothing else. they aren't all that useful to programmers in
higher-level languages, who can get the exact same services by other
means. oh, apart from the hype-factor, of course.

Martin Rodgers

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

Erik Naggum wheezed these wise words:

> if you mean Allegro CL specifically for Windows, please say so. I have
> never been a fan of Allegro for Windows; it's a radically different and
> much inferior product in all interesting ways to Allegro CL for Unix, the
> Real Thing.

It's just one of those unfortunate products to have been developed by
one company and then bought by another. Equal confusion may result
from calling two completely different compilers Symantec C++. This is
a marketing problem, not a Lisp problem. Certainly not an OS problem.

I like ACL/PC best of all the Lisps I've used. Unfortunately, I can't
afford it, so I bought LWW instead. Let's not play Endian Wars. Let's
not get into OS politics here, in comp.lang.lisp. There are enough
advocacy newsgroups already, as I'm sure you're aware.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe

Simon Leinen

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

Erik Naggum <cle...@naggum.no> writes:
> [...] OS-level "threads" are mainly useful to C programmers, who

> can get nothing else. they aren't all that useful to programmers
> in higher-level languages, who can get the exact same services by
> other means. oh, apart from the hype-factor, of course.

And parallel execution of threads on multi-processor machines.
--
Simon Leinen si...@babar.switch.ch
SWITCH http://www.switch.ch/misc/leinen/

Who is General Failure & why's he reading my disk?

Chuck Fry

unread,
Apr 6, 1998, 3:00:00 AM4/6/98
to

In article <31008700...@naggum.no>, Erik Naggum <cle...@naggum.no> wrote:
> if you mean Allegro CL specifically for Windows, please say so. I have
> never been a fan of Allegro for Windows; it's a radically different and
> much inferior product in all interesting ways to Allegro CL for Unix, the
> Real Thing.

My sources at Franz tell me they have unified the Windows and Un*x
sources for ACL 5.0. Their promotional literature hints at the same
thing. It couldn't have been a trivial job, considering that ACL4Win
was basically a product they bought from another vendor.

I use ACL 4.3 in my day job and consider it as good as anything
currently available for modern workstations. But I still miss
Symbolics. In some respects, the rest of the world is *still* catching
up to where Symbolics was a decade ago.

> while multithreading and all the cool stuff may be quite the novelty
> under Bill Gates' dysfunctional regime, it has actually existed and been
> taken for granted elsewhere for several decades. It's saddening that
> people actually believe that something so old is in any way new or worthy
> of interest. the world should have shouted "god damn it, Bill, what the
> heck _took_ you so long!?" instead of embracing his belated junkware.

Seconded. FWIW, I worked for a company in 1980 that already had a
multi-user Basic system -- on the *8080*. Why it should take the PC
world so long to get around to multitasking is beyond me.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
chu...@chucko.com (text only please), chuc...@home.com (MIME enabled),
chu...@gateway.idiom.com (SPAM ONLY)

Kent M Pitman

unread,
Apr 7, 1998, 3:00:00 AM4/7/98
to

Erik Naggum <cle...@naggum.no> writes:

> OS-level "threads" are mainly useful to C programmers,
> who can get nothing else.

They do get you separated address space. Lisp multi-tasking is in the
same environment, usually. All in all, given a choice of only one,
I'd rather have muti-tasking be in the same environment for ease of
sharing objects in a single address space. But some people don't agree.
Some number of them are perhaps just confused, or not acclimated to
Lisp, but some have legitimate needs. OS-level processes do GC quickly
when done, for example, and for SOME (not all) applications, that's a
big win.

We shouldn't be fighting over which is better. Each has its virtue
and people should be trained to use the right tool for the right task.
The main problem with C is that it teaches people to believe that
those things not conveniently available are not to be wished for.
Let's not join them on that self-limiting view.

A system which supports "choice" is better off.

John Foderaro

unread,
Apr 7, 1998, 3:00:00 AM4/7/98
to

Don Geddis wrote:

>
> I've heard rumors that the delay in ACL 5.0 is due to Franz interfacing the
> threads package more directly with the native operating system processes. This
> is apparently difficult, especially under Windows NT.
>

It is true that in Acl 5.0 on Windows (NT and 95) each Lisp
lightweight process runs in a separate operating system thread.
This wasn't just a neat idea, it was a requirement to handle
calls into Lisp from such sources as OLE/COM.
Only one thread at a time can be executing Lisp code, however
threads that call into C can declare that they no longer need control
of the lisp heap, and in that case they are free to run whenever
the operating system gives them a time slice. Thus you can actually
have a lisp application running on multiple processors (although again
let me state that only thread can be running actual lisp code).

A sample application I'm writing that demonstrates this
feature is a web server. In a web server each thread does this
repeatedly
1. wait for connection
2. read and parse http request.
3. determine what should be sent in response
4. send the response

Most of the (real) time is spent in steps 1,2, and 4 (since
communication
can be slow), and these steps are easy to write in C.
Step 3 is the interesting part, especially if you have automatically
generated pages. Interesting programs are best written in Lisp.
Thus the problem partitions into a C part (1,2,4) and a Lisp part (3).
This is an example of a lisp application that could make use of a
multiprocessor machine.

How about the other platforms? Well, while I am no fan of the
Windows so-called Operating system, it does a better job of dealing
with threads than Unix, where threads are clearly an afterthought.
We did port the native thread lisp to each Unix platform and while
some Unix thread libraries worked ok, many did not. [I don't want
to name names here, though]. But threads are important and
we see constant improvements from the OS vendors and we hope to have
native OS threads working in all platforms in the release after 5.0.

john foderaro
franz inc.

Zellyn Hunter

unread,
Apr 7, 1998, 3:00:00 AM4/7/98
to

Kent M Pitman (pit...@world.std.com) wrote:
: They do get you separated address space. Lisp multi-tasking is in the

: same environment, usually. All in all, given a choice of only one,
: I'd rather have muti-tasking be in the same environment for ease of
: sharing objects in a single address space. But some people don't agree.

How do you prevent problems of name-clashes? We did some multi-thread
stuff in acl for linux, and wrote code to a file, reading it in to
a different package, to prevent this.

What I'd like is a nicer way to spawn off processes on a network
connection that are reasonably "safe" from each other - in terms
of defining functions or "global" variables.

Just wondering if there was a nice solution out there that I missed.

Thanks,

Zellyn

--
,db. ,db. "For You knit me together in my mother's
_,o88b. 8'`8 8'`8 womb. I praise You because I am fearfully
dP' `Yb ,db. 8 8 Y 8 and wonderfully made."
" d8 8' 8 Y ,P Y ,P db b b ,gg.
.oP' Y,d' `bd' `bd' 88 8b `8P `Y,
`Y, dP. ,Pb. ,Pb. ,PY. ,88 dP 88 ,d' Zellyn Hunter
d8 dP' "YgP' `YgP' `YgP' YggP"Y8oP8 `YggP zellyn @ bigfoot.com
-,o-----88-------------------------,dP-8'---------------------------------
Yb .dP' _,d8' 8P
`Y888P' ,dP' dP
8' ,dP
`YgggP"

Kent M Pitman

unread,
Apr 8, 1998, 3:00:00 AM4/8/98
to

zel...@cc.gatech.edu (Zellyn Hunter) writes:

> Kent M Pitman (pit...@world.std.com) wrote:
> : I'd rather have muti-tasking be in the same environment for ease of
> : sharing objects in a single address space.
>

> How do you prevent problems of name-clashes? We did some
> multi-thread stuff in acl for linux, and wrote code to a file,
> reading it in to a different package, to prevent this.

Maybe avoid writing code that depends for its partitioning on the symbol
namespace? e.g., store your data in one or more objects (hash tables
or CLOS standard objects or whaever) bound to lexical or special
variables in the process. Then arrange for each process to get a fresh
object.

Jens Kilian

unread,
Apr 8, 1998, 3:00:00 AM4/8/98
to

Jon S Anthony <j...@synquiry.com> writes:
> ??? OS thread support is (well, can't think of a counterexample
> anyway) in the same address space. We're not talking old UNI*
> separate _processes_ here. To me the basic win of using OS threads is
> that you get all the synchronization, locking, etc. across the full OS
> spectrum of activities (in particular you get non-blocking IO with OS
> threads "for free"). The downside is that these things are _way_
> slower than, say, an "internal" task/thread support for a specific
> language implementation.

Not in a properly designed OS.

Jens.
--
mailto:j...@acm.org phone:+49-7031-14-7698 (HP TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-14-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]

Tim Bradshaw

unread,
Apr 13, 1998, 3:00:00 AM4/13/98
to

* Erik Naggum wrote:

> why do you quote _thread_ just because Allegro doesn't use one particular
> implementation of a well-known technology with lots of very different

> implementations? OS-level "threads" are mainly useful to C programmers,
> who can get nothing else. they aren't all that useful to programmers in


> higher-level languages, who can get the exact same services by other
> means. oh, apart from the hype-factor, of course.

I don't think that's right, or not necessarily right. There are a lot
of things that you want a thread system to be able to provide which
can be provided either best or only at OS level -- things like making
sure IO works right, and dealing with multiprocessors effectively are
best done at OS level. So you'd want your lisp threading system to be
built on a decent OS-level threading system, where such exists, I
think.

--tim

Robert P. Krajewski

unread,
Apr 15, 1998, 3:00:00 AM4/15/98
to

In article <ey31zv2...@dubh.aiai.ed.ac.uk>, Tim Bradshaw
<t...@aiai.ed.ac.uk> wrote:

> So you'd want your lisp threading system to be
> built on a decent OS-level threading system, where such exists, I
> think.

Another very good reason for using OS-level threads as the basis for
language-level threads is to ease integration with code that is running in
the same thread, or address space, but written in a different language.

For example, until about JDK 1.1.3 or so, Sun's Java implementation on
Solaris could not be embedded in certain progams because the VM used
"fake" threads, and intercepted certain OS calls in order to make them
work.

The Win32 implementaton never had this problem because it always used
native threads.

Bruno Haible

unread,
Apr 15, 1998, 3:00:00 AM4/15/98
to

>> Not in a properly designed OS.
>
> Fair enough. Can't really disagree with that. OTOH, how many such
> things are "largely used" commercial platforms? :-(

Most operating systems have native OS thread support: Linux >= 2.0.20,
Win32, Solaris 2.6, DEC Alpha OSF/1, HP-UX 11, Irix 6.3, and even AIX has
it or is not too far away. It's just like hypertext: it took 20 years
to get accepted, but now it's there.

Bruno http://clisp.cons.org/~haible/

Rainer Joswig

unread,
Apr 16, 1998, 3:00:00 AM4/16/98
to

In article <6h2aq1$188$1...@nz12.rz.uni-karlsruhe.de>, hai...@clisp.cons.org
(Bruno Haible) wrote:

> >> Not in a properly designed OS.
> >
> > Fair enough. Can't really disagree with that. OTOH, how many such
> > things are "largely used" commercial platforms? :-(
>
> Most operating systems have native OS thread support: Linux >= 2.0.20,
> Win32, Solaris 2.6, DEC Alpha OSF/1, HP-UX 11, Irix 6.3, and even AIX has

MacOS, too.

--
http://www.lavielle.com/~joswig/


Georg Bauer

unread,
Apr 16, 1998, 3:00:00 AM4/16/98
to

>MacOS, too.

For a quite special definition of "thread", though. It's not that the
multitasking of the MacOS is _that_ impressive. I want Rhapsody. Now. :-)

bye, Georg

--
#!/usr/bin/perl -0777pi
s/TS:.*?\0/$_=$&;y,a-z, ,;s, $,true,gm;s, 512,2048,;$_/es

Rainer Joswig

unread,
Apr 17, 1998, 3:00:00 AM4/17/98
to

In article <gb-160498...@hugo.westfalen.de>, g...@hugo.westfalen.de
(Georg Bauer) wrote:

> >MacOS, too.
>
> For a quite special definition of "thread", though.

Due to the multitasking properties of the MacOS.

> I want Rhapsody. Now. :-)

I'd only use Rhapsody if MCL would be available. ;-)

--
http://www.lavielle.com/~joswig/


Espen Vestre

unread,
Apr 17, 1998, 3:00:00 AM4/17/98
to

jos...@lavielle.com (Rainer Joswig) writes:

> > I want Rhapsody. Now. :-)
>
> I'd only use Rhapsody if MCL would be available. ;-)

Hmm, I wouldn't be unhappy with ACL for Rhapsody. If
Rhapsody gains enough interest, I would guess that Franz would
have an easy job porting ACL to Rhapsody/PPC (after all they
already have an AIX version....).

--

Espen Vestre

Rainer Joswig

unread,
Apr 17, 1998, 3:00:00 AM4/17/98
to

True. But it would look alien to Rhapsody.

MCL also has the better UI/environment (IMHO).

--
http://www.lavielle.com/~joswig/


Carl Shapiro

unread,
Apr 17, 1998, 3:00:00 AM4/17/98
to

Espen Vestre <e...@nextel.no> writes:

[...]

> Hmm, I wouldn't be unhappy with ACL for Rhapsody. If
> Rhapsody gains enough interest, I would guess that Franz would
> have an easy job porting ACL to Rhapsody/PPC (after all they
> already have an AIX version....).

As well as an NeXTstep version which came standard with the original
NeXT Computer :-)

So it would seem that all the pieces are allready there (in one form
or another).


Carl

0 new messages