Threads vs. continuations

[miller.paul.w@gmail.com]

I've been doing some thinking, and I've halfway convinced myself of
the following statement: that threads as implemented by Python (or
Java) are exactly equivalent to one-shot continuations in Scheme. Am
I right? (I'd have asked in the scheme groups, but I feel like I'm
less likely to get flamed to death here... hehe.)

If that's the case, it seems threads plus hygeinic macros and a few
primitives a la Scheme would form a solid basis upon which to build a
programming language. The only thing preventing Python from being
that language is the difficulty of integrating a macro system, n'est-
ce pas?

Thanks!

Paul

[Tim Daneliuk]

Re: Threads vs. continuations

miller.paul.w@g mail.com wrote:

I've been doing some thinking, and I've halfway convinced myself of
the following statement: that threads as implemented by Python (or
Java) are exactly equivalent to one-shot continuations in Scheme. Am
I right? (I'd have asked in the scheme groups, but I feel like I'm
less likely to get flamed to death here... hehe.)
>
If that's the case, it seems threads plus hygeinic macros and a few
primitives a la Scheme would form a solid basis upon which to build a
programming language. The only thing preventing Python from being
that language is the difficulty of integrating a macro system, n'est-
ce pas?
>
Thanks!
>
Paul

An interesting question to which I shall stay tuned for an answer.

However, allow me to point out that there is a macro language for
Python. It's called 'm4' ... <ducks and runs>

--
----------------------------------------------------------------------------
Tim Daneliuk tundra@tundrawa re.com
PGP Key: http://www.tundraware.com/PGP/

[Aahz]

Re: Threads vs. continuations

In article <061541c8-1f37-42bc-8041-170fee9707b4@h2 5g2000hsf.googl egroups.com>,
<miller.paul.w@ gmail.comwrote:

>
>If that's the case, it seems threads plus hygeinic macros and a few
>primitives a la Scheme would form a solid basis upon which to build a
>programming language. The only thing preventing Python from being
>that language is the difficulty of integrating a macro system, n'est-
>ce pas?

"Difficulty " as measured in Guido being less likely than the survival of
a snowball in the Sahara to ever consider anything like hygenic macros.
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of
indirection." --Butler Lampson

[Arnaud Delobelle]

Re: Threads vs. continuations

On Feb 19, 8:26 pm, miller.pau...@g mail.com wrote:
[...]

The only thing preventing Python from being
that language is the difficulty of integrating a macro system, n'est-
ce pas?

Well there's logix (http://www.livelogix.net/logix/)


--
Arnaud

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: Threads vs. continuations

I've been doing some thinking, and I've halfway convinced myself of

the following statement: that threads as implemented by Python (or
Java) are exactly equivalent to one-shot continuations in Scheme. Am
I right?

No. In case of threads, progress can be made in an overlapping
(concurrent), in case of Java even parallel fashion. In particular,
if a thread blocks in a blocking operating system call (e.g. a network
receive operation), other threads can continue. I believe this is not
possible with continuations in Scheme.

In more detail, threads as provided by the operating system underly
a system scheduler: they can be preempted, they have priorities,
and they may voluntarily block. All this is not possible with
continuations.

IOW, threads are more expressive than continuations.

Regards,
Martin

[Paul Rubin]

Re: Threads vs. continuations

Tim Daneliuk <tundra@tundraw are.comwrites:

'Not trying to start a fight here, I'm just curious about the
current state of that art. It is the case today that all
modern language threading is realized over a kernel implementation
of threading that behaves as you suggest?

Certainly not. See Erlang, Haskell, Concurrent ML, etc.
The low level i/o in the runtime systems for those languages has
to be written to never block, but the payback is much lighter weight
user threads.

[John Nagle]

Re: Threads vs. continuations

Tim Daneliuk wrote:

Martin v. Löwis wrote:

Is/Was it not the case, though, that some languages present
a threading model to the programmer that is realized in user
space, but not in the kernel. ISTR some early implementations
of Posix Threads that worked that way. The API was there
and was correct, but - since everything was actually running
in user space - when a single "thread" blocked, they all did.

People did things like that to hammer threading onto operating
systems so dumb they couldn't context switch, like
DOS, early Windows, and MacOS through 7. Nobody does that
any more.

For one thing, it's easier to build a real scheduler
than to build the hacks for working without one. (Mac programmers
referred to this as the Mess Inside - no real CPU dispatcher, but
"deferred tasks", "timer tasks", "vertical interval tasks", and
similar hacks to work around the lack of one.)

John Nagle

[Paul Rubin]

Re: Threads vs. continuations

John Nagle <nagle@animats. comwrites:

People did things like that to hammer threading onto operating
systems so dumb they couldn't context switch, like
DOS, early Windows, and MacOS through 7. Nobody does that
any more.

I see stuff heading more the other way; here's a description of a test
of Erlang with 20 million (userspace) threads:

http://groups.google.com/group/comp.lang.functional/msg/33b7a62afb727a4f

I don't know of any OS's that can handle that many threads.
Lightweight userspace threads also makes it sane to do things like
make GUI's with a separate thread per widget, and in general to
handle large numbers of concurrent tasks without the large memory
footprint and context switch overhead of kernel level threads.