Threads vs. continuations

[miller.paul.w]

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]

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>

 

[Aahz]

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.

 

[Arnaud Delobelle]

On Feb 19, 8:26 pm, (e-mail address removed) 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/)

 

[Martin v. Löwis]

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

 

[Tim Daneliuk]

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

That's assuming that the threading implemented at the language
level is actually realized by underlying kernel threading.
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.

'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?

 

[Paul Rubin]

'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.

 

[Martin v. Löwis]

That's assuming that the threading implemented at the language

level is actually realized by underlying kernel threading.
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.

You were asking about Python and Java specifically. Python
has been using OS threads as its threading foundation ever
since operating systems started supporting threads (there is
still support for user-level thread libraries in Python,
but I doubt it's still in use anywhere). Java had different
versions of the JVM in the past, one that supported only
user-mode threads, but likewise, these got out of use quite
some time ago.

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.

No, not in any good user-mode thread library. E.g. the GNU Pth
library manages to provide user-mode dispatching and provides
wrappers for blocking calls that dispatch to a different thread
if blocking would occur.

'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?

I didn't suggest it for all languages, only for Python (or Java),
see your original posting.

Regards,
Martin

 

[John Nagle]

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]

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.