Simon Marlow wrote:
> > do
> > r <- return (mersenne' 44)
> > acquire'lock
> > putStrLn "Great success"
> > print r
> > release'lock
> > One may think that the long computation occurs in the "r <- ..." line.
> > Alas, it may just as well occur in the "print r" line, when th
On 12 April 2006 11:30, John Meacham wrote:
> On Wed, Apr 12, 2006 at 11:19:53AM +0100, Simon Marlow wrote:
>> The safe points don't even have to be very often: in GHC the context
>> switch check is made after every 4k of allocation.
>
> indeed, which means GHC technically doesn't meet the preem
On Wed, Apr 12, 2006 at 11:19:53AM +0100, Simon Marlow wrote:
> I'll argue that point :) GHC makes run-time checks at safe points and
> implements preemptive concurrency. Cooperative scheduling is when the
> *programmer* has to insert the safe points.
the programmer of the standard libraries or
On 12 April 2006 11:03, John Meacham wrote:
> On Wed, Apr 12, 2006 at 10:24:57AM +0100, Simon Marlow wrote:
>> On 12 April 2006 08:41, John Meacham wrote:
>>
>>> However, I am also of the mind that preemtiveness alone doesn't buy
>>> enough to make the runtime cost of locking worth it which is wh
On Wed, Apr 12, 2006 at 10:24:57AM +0100, Simon Marlow wrote:
> On 12 April 2006 08:41, John Meacham wrote:
>
> > However, I am also of the mind that preemtiveness alone doesn't buy
> > enough to make the runtime cost of locking worth it which is why I
> > plan for jhc to be fully cooperative or f
On 12 April 2006 07:46, [EMAIL PROTECTED] wrote:
> I am afraid I must ask for the clarification of the goals of this
> discrimination between pre-emptive and cooperative scheduling -- which
> leads me to further questions.
>
> One one hand, I understand the motivation: providing guidance to the
>
On 12 April 2006 08:41, John Meacham wrote:
> However, I am also of the mind that preemtiveness alone doesn't buy
> enough to make the runtime cost of locking worth it which is why I
> plan for jhc to be fully cooperative or fully OS threaded with no
> middle ground. but the situation is different
Fortunatly, I don't expect these issues to be much of a problem in
practice. (though, they certainly are real issues)
the vast majority of programs, haskell ones included, are either
interactive or batch. an interactive program spends most of its time
waiting for user input or external events, res
John Meacham 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.
> would the simple qualifier
> 'if there exists another runnable thread'
> solve the issues?
if