By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,885 Members | 1,499 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,885 IT Pros & Developers. It's quick & easy.

Threads vs. continuations

P: n/a
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
Feb 19 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
mi***********@gmail.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 tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Feb 19 '08 #2

P: n/a
In article <06**********************************@h25g2000hsf. googlegroups.com>,
<mi***********@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 (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of
indirection." --Butler Lampson
Feb 19 '08 #3

P: n/a
On Feb 19, 8:26*pm, miller.pau...@gmail.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

Feb 19 '08 #4

P: n/a
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
Feb 19 '08 #5

P: n/a
Tim Daneliuk <tu****@tundraware.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.
Feb 19 '08 #6

P: n/a
Tim Daneliuk wrote:
Martin v. Lwis 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
Feb 20 '08 #7

P: n/a
John Nagle <na***@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....b7a62afb727a4f

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.
Feb 20 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.