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,
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 in
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
end
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 why I
plan
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: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 preemptive
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 the digits
of the
