On 12 April 2006 17:51, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
By infinite loop, you mean both non-terminating, and non-productive.
A non-terminating but productive pure computation (e.g. ones =
1:ones) is not necessarily a problem.
That's slightly odd terminology.
On 13 April 2006 10:53, John Meacham wrote:
On Thu, Apr 13, 2006 at 09:46:03AM +0100, Simon Marlow wrote:
You seem to be assuming more about cooperative scheduling than eg.
Hugs provides. I can easily write a thread that starves the rest of
the system without using any _|_s. eg.
let
On Wed, Apr 12, 2006 at 05:50:40PM +0100, Malcolm Wallace wrote:
The argument John was making is that this is a useful distinguishing
point to tell whether your concurrent implementation is cooperative or
preemptive. My argument is that, even if you can distinguish them in
this way, it is not
On 11 April 2006 22:24, John Meacham wrote:
I'd like to be a bit more formal when it comes to the distinction
between cooperative and preemptive implementations of concurrency,
here is a first attempt.
1. termination,
In a concurrent implementation, a thread performing an infinite loop
On Wed, Apr 12, 2006 at 10:58:32AM +0100, Simon Marlow wrote:
I don't know what it means for a thread to have value _|_. A thread
is defined by its observable effects, threads don't have values.
sure they do, the value is just usually discarded. cooperative
implementations are just the ones
John Meacham [EMAIL PROTECTED] wrote:
In a concurrent implementation, a thread performing an infinite loop
with no IO or interaction with the outside world can potentially stall
switching to another thread forever, in FP, we usually denote an
infinite loop by _|_. so I think the first
Simon Marlow [EMAIL PROTECTED] wrote:
By infinite loop, you mean both non-terminating, and non-productive.
A non-terminating but productive pure computation (e.g. ones =
1:ones) is not necessarily a problem.
That's slightly odd terminology. ones = 1:ones is definitely
terminating.
On Wed, Apr 12, 2006 at 05:50:40PM +0100, Malcolm Wallace wrote:
The argument John was making is that this is a useful distinguishing
point to tell whether your concurrent implementation is cooperative or
preemptive. My argument is that, even if you can distinguish them in
this way, it is not
On 4/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[Rule 1]
* in a cooperative implementation of threading, any thread with value
_|_ may cause the whole program to have value _|_. In a preemtive one,
this is not true.
I'm afraid that claim may need qualifications:
I was
On Tue, Apr 11, 2006 at 09:05:12PM -0700, [EMAIL PROTECTED] wrote:
[Rule 1]
* in a cooperative implementation of threading, any thread with value
_|_ may cause the whole program to have value _|_. In a preemtive one,
this is not true.
I'm afraid that claim may need qualifications:
10 matches
Mail list logo
