Threads vs. continuations

[Tim Daneliuk]

Martin v. Löwis 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?
> 
> 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?



-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/