Simon Peyton-Jones <[EMAIL PROTECTED]> answers my question:
>
> | This is something that I have long been wondering about
> | (perhaps it is just because of my ignorance):
> | Wouldn't stable pointers be a cheaper and more appropriate means
> | to get Ord for MVars, STRefs, and IORefs?
>
Hi,
Sorry to bother the list with a purely installation problem, but I
downloaded the latest i386-unknown-linux binary, plus happy-1.6 and
can't get them run. It installs properly, but when I start the binaries
it reports
libgmp.so.2: ELF file's phentsize not the expected size
libgmp is from t
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote,
> I'm sorry to say that profiling simply doesn't work in
> recent versions of GHC. I believe it does in 3.02, but
> even that appears to be broken if you have a recent version
> of Linux (as we do).
Vanilla heap profiling (ie, -h or -hC) worked in t
Tue, 15 Feb 2000 18:57:51 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> > The requirement could be even stronger, that the integers are
> > increasing, so one can compare relative time of IO events without
> Absolutely not. If you have 5000 processors, how are they to work out
> which one d
Hi.
George Russell writes:
> I _think_ your (Tom Pledger's) solution can deadlock.
> Suppose we have two simultaneous calls to lowerFlags
> (call 1) lowerFlags f1 f2
> (call 2) lowerFlags f2 f1
> Then we have
>
> (initially f1 and f2 are both Up)
> Call 1
Marcin 'Qrczak' Kowalczyk wrote:
[snip]
> The requirement could be even stronger, that the integers are
> increasing, so one can compare relative time of IO events without
Absolutely not. If you have 5000 processors, how are they to work out
which one did an IO event first? I don't really see th
Tue, 15 Feb 2000 14:14:09 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> I think Integer is a little too specific - how about
>
> type Unique implements (Ord,Eq)
> newUnique:: IO Unique
Somebody may want to generate unique idenifiers or unique values of
another concrete type.
The requireme
George Russell wrote:
> Does the phrase "Dining Philosophers Problem" ring a bell with anyone?
And AFAIK, the existing solutions to that problem requires a knowledge
of who all the philosophers are and what they are attempting to do. That
gets back to the issue of having a global value that store
Simon Peyton-Jones wrote:
> I think what you want is a distributed way to get a unique,
> as George suggested. Then you can pair that with an MVar when
> you want something comparable. The unique can include the processor
> id, so it can be globally unique. 64 bits?
>
> I'm still leery of putt
George Russell wrote:
> Exactly the same happens at the same time to Processor 2.
> Now somehow you have to distinguish between Processor 1 and Processor 2,
> because only one is going to get to lower the flags. But I don't think
> with the existing Concurrency extensions plus standard Haskell yo
| This is something that I have long been wondering about
| (perhaps it is just because of my ignorance):
| Wouldn't stable pointers be a cheaper and more appropriate means
| to get Ord for MVars, STRefs, and IORefs?
Could be -- but do we really want to clog up the stable-pointer table
with an en
(Michael Hobbs solution excised)
But this code could potentially loop forever! Surely that's just as bad
as deadlocking??
Marcin 'Qrczak' Kowalczyk wrote:
> If the IO monad can maintain a random number generator, it can as
> well mainain unique Integer supply. The interface is clean.
It can, but according to the current specification, it doesn't. Maybe
it should. I think Integer is a little too specific - how about
Tue, 15 Feb 2000 11:20:45 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> In this case it could be filled by having a supply of guaranteed
> distinct elements from a linear order, which doesn't have to require
> a central dispatch centre. (For example, you could allocate them
> on each proces
Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
>
> | elegant. If MVar's were instances of Ord as well as Eq, a
> | neat solution would
> | be to always get the least MVar first, but they aren't. So
> | what should one do?
>
> But you could make Flag an instance of Ord
>
> dat
Simon Peyton-Jones wrote:
> Now newMVar needs to consult a global variable to get the
> next Flag number, but after that there's no global locking.
I really don't like this at all. Suppose we have Concurrent Haskell
running on 5000 processors, then every time I want to set this sort of
thing up I
| elegant. If MVar's were instances of Ord as well as Eq, a
| neat solution would
| be to always get the least MVar first, but they aren't. So
| what should one do?
But you could make Flag an instance of Ord
data Flag = MkFlag Int (MVar Bool)
Now newMVar needs to consult a global va
Folks,
I'm sorry to say that profiling simply doesn't work in
recent versions of GHC. I believe it does in 3.02, but
even that appears to be broken if you have a recent version
of Linux (as we do).
It's not all bad news. Stephen Jarvis is spending a mini-sabbatical
here at MSR, with the aim of
18 matches
Mail list logo
