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
On 13 April 2006 11:41, Malcolm Wallace wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> wrote:
>
>>> Well, the expression "ones" on its own is non-terminating.
>>
>> under what definition of non-termination? Non-termination has meant
>> the same as _|_ in a call-by-name semantics as far as I'm conc
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.
>>
>
"Simon Marlow" <[EMAIL PROTECTED]> wrote:
> > Well, the expression "ones" on its own is non-terminating.
>
> under what definition of non-termination? Non-termination has meant
> the same as _|_ in a call-by-name semantics as far as I'm concerned,
> and "ones" is most definitely not == _|_.
Ok,
On Thu, Apr 13, 2006 at 02:53:01AM -0700, John Meacham wrote:
> this is a non-productive non-cooperative loop, as in _|_. since IORefs
I mean
this is a non-productive non-terminating loop, as in _|_. since IORefs
John
--
John Meacham - ⑆repetae.net⑆john⑈
__
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 loop = do x <- readIORef r; writeIORef r (x+
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
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
"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
> term
On 12 April 2006 11:41, Malcolm Wallace wrote:
> 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 de
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 di
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
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
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 qualific
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:
> [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:
1. if there is only one runnable thread, if it loops in pure code,
t
16 matches
Mail list logo
