November 2002 - Glasgow-haskell-users

RE: first stab at -ffunction-sections
by Simon Marlow 18 Nov '02

18 Nov '02

> This could be an artifact of the -j64 (BTW, has anyone else > noticed the > makefiles can only keep 5 or 6 cpus busy at a time much of the time, > and often less?). There are probably still bugs in our build system w.r.t. make -jN. I occasionally use it to build the compiler, but rarely any other parts of the system. What exactly are you trying to use -ffunction-sections for? I'm pretty sure it won't work as things stand currently, unless you can guarantee to be able to find a text/data boundary symbol for the garbage collector (currently it has to be able to distinguish text from data, we're in the process of lifting the restriction but it's a lot of work). Cheers, Simon

1 0

RE: Native Threads in the RTS
by Simon Marlow 18 Nov '02

18 Nov '02

> We can't currently allow several Haskell threads to really run > simultaneosly [e.g. on two separate processors, or preemtively > scheduled on a single processor], because they always mutate the same > global heap. Currently, GHC switches its green threads only at times > when the heap is in a defined state [not truly preemptively]. There > seems to be some SMP support in the RTS, I don't know if it ever > worked. If anyone wants to fix/finish it, that would be > great, but it's not what I'm proposing here. The SMP support is an experiment that was never finished. There are serious issues to be solved regarding reducing the locking overhead on a shared-memory heap. > My proposal is only a minimum solution intended to resolve > the inherent > incompatibility between the "threaded RTS" and libraries like OpenGL, > which require thread-local-state. I think I'm happy with that, although I don't have the whole context swapped in. That seems to be the conclusion we came to at the last discussion, though: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-June/003592. html Cheers, Simon

1 0

RE: Native Threads in the RTS
by Simon Marlow 18 Nov '02

18 Nov '02

> I'm still unconvinced that the current optional > RTS support for mixed green/native threads is the right way > to go. It looks to > me like a workaround for poor OS support for really > lightweight threads. It is a workaround for the lack of truly lightweight threads at the OS level. But I don't expect that situation to change, even with the recent improvements on the Linux front. The new RedHat Linux threads folk claim to be able to create 10^5 threads in a couple of seconds, whereas we can create 10^6 threads in about that time (on an old 500MHz machine, too). Cheers, Simon

1 0

RE: Silly question about IORefs and MVars
by Simon Marlow 18 Nov '02

18 Nov '02

> I have a silly question about IORefs and MVars. > > When do we have to use MVars if a var is accessed by multiple > threads. > In fact, I wonder why IORefs updates aren't safe : > it seems that preemptive scheduling takes place during memory > allocation > and I can't see where there could be an allocation (and so a > switch) in > a read or a write of an IORef. The problem is how to read the IORef, modify its contents, and write the new value back without being preempted. You can do this easily with an MVar, but not an IORef. > Related question : how less performant is a MVar comparated to simple > ref. reading/writing an MVar is an out-of-line call, whereas the IORef operations are all inline. I don't know the figures though. Recently we added atomicModifyIORef which should allow IORefs to be used in some cases where MVars were required before. We haven't settled on the exact interface yet, though. Cheers, Simon

1 0

RE: Native Threads in the RTS
by Simon Peyton-Jones 18 Nov '02

18 Nov '02

| I propose adding something like | | forkNativeThread :: IO () -> IO () I haven't talked to Simon about this, but it sounds possible. Three thoughts. First, before doing anything like this I'd like to ask you or someone else, or a group, to write a clear exposition of what the problem is and what the solution is, to add to the GHC user manual. (If there are implementation related questions, they can go into the Commentary.) As you say, this is a topic that we have visited regularly, and it's a slippery one, so I'd like to capture it. Second, there's the question of what it really means. In particular, what if that thread forks further (Haskell, green) threads? Are they too bound to the native thread? A library you call might in principle fork threads to get its job done... Third | If a callback is entered and the current OS thread corresponds to a | native haskell thread, the callback should be executed in the current | OS thread. | Other haskell threads continue to run in the worker thread or in their | own dedicated OS thread. I'm not sure what this means. What is the "current" OS thread? Perhaps an example? Simon

1 0

RE: Bug? [was: Implicit params]
by Simon Peyton-Jones 15 Nov '02

15 Nov '02

| > this seems like a bug in GHC. Hugs is happy with it. The "s" in the | > pure2 signature is not ambiguous because it is determined when you give | > the value of the implicit parameter. in fact the way i think about | > implicit parameters is simply as a nice notation for computations in the | > environment monad, so in my mind the above two definitions are pretty | > much the same. | | Thanks Iavor! | GHC people, can you confirm this, Is it a bug? I'm using Ghc 5.0.4 SuSE rpms. | Is there a workaround? Interesting. I hadn't thought of that. Yes, I think you can consider it a bug, or at least the lack of a feature. I'll fix it next week S

1 0

RE: Help: Windows ghc profiler errors
by Simon Marlow 15 Nov '02

15 Nov '02

> I want to profile my Haskell program (it solves the Queens and Knights > problem stated here: > http://www.itasoftware.com/careers/programmers.php ). > I'm compiling with GHC 5.04.1 under Windows NT using the > following command > line (as per the Users Guide): > > >ghc -prof -auto-all -o queens --make Main > > > When I run the program with the following command lines I get: > > >queens > queens: fatal error: evacuate: strange closure type 1696 Profiling is broken on Windows in 5.04.1. I think we know what the problem is, and it will be working again in 5.04.2. Sorry about that. Cheers, Simon

1 0

RE: bug in unix/System/Posix/Files.hsc
by Simon Marlow 15 Nov '02

15 Nov '02

> In local.glasgow-haskell-users, you wrote: > > readSymbolicLink is broken, it assumes that readlink(2) > null terminates its > > result when it doesn't. this causes all sorts of badness. > > This should fix it, although all my CVS trees are hosed right now > (now how did I manage to break something in the backup tree?) and I > can't actually test it: <patch snipped> Thanks, I'll check it in. As you probably guessed, this stuff hasn't had any testing yet. Cheers, Simon

1 0

bug in unix/System/Posix/Files.hsc
by John Meacham 15 Nov '02

15 Nov '02

readSymbolicLink is broken, it assumes that readlink(2) null terminates its result when it doesn't. this causes all sorts of badness. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 1

RE: strange error
by Simon Marlow 14 Nov '02

14 Nov '02

> sorry for the terse error report, but I was on my way out the door and > didn't want this to slip through. It appeared after running a rather > large complicated haskell program all night, the next morning it had > crashed with > fatal error: evacuate: strange closure type 55436 There has been one bug found in the garbage collector since 5.04.1, which might have caused this. Presumably if you ran the same program under the same conditions it would fail in the same way (how long does it take to fail?). Is there any chance you could compile up the latest CVS sources from the 5.04 branch and see if using that compiler helps? Cheers, Simon

2 1