Re: -threaded
Christian Maeder schrieb: Could you summarize the advantages (or need) of the threaded RTS? It doesn't work under solaris I'm quite content with my non-threaded 6.4.2-cvs version under solaris (and I was already looking for a switch -non-threaded under linux). C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Christian Maeder [EMAIL PROTECTED] wrote: It doesn't work under solaris and under linux [1] my nightly compilation jobs are killed every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before. A process can be Killed by the operating system if the machine runs out of virtual memory. I suspect someone else is running a cron job on Tuesdays that fills memory. It is unlikely to be (only) ghc's fault. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Christian Maeder wrote: Simon Marlow schrieb: Gregory Wright wrote: Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution. This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD. Could you summarize the advantages (or need) of the threaded RTS? The reason we added it to the compiler was so that you could use programs that require -threaded under GHCi. Without it, these programs cannot be used with GHCi. In general, -threaded is the way forward, and at some point I hope we can make it the default (I was considering this for 6.6, actually). Without -threaded, all FFI calls block the other threads in the program, and this makes it impossible to do lots of things. It doesn't work under solaris and under linux [1] my nightly compilation jobs are killed every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before. What version of glibc are you using on Linux? There were bugs in glibc that could cause deadlocks occasionally, I remember having to upgrade glibc on our RedHat 9 box a while back. We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be released without a fix for this. I'm actually quite glad that we've forced this into the open with 6.4.2, otherwise the bug would probably have remained dormant, affecting only those who used -threaded on Sparc. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Simon Marlow schrieb: The reason we added it to the compiler was so that you could use programs that require -threaded under GHCi. Without it, these programs cannot be used with GHCi. Surely, running user programs is different from just compiling. Without -threaded, all FFI calls block the other threads in the program, and this makes it impossible to do lots of things. Obviously, I only want that (my old) sequentiell things are done as reliable (one at a time) as before. What version of glibc are you using on Linux? glibc-devel-2.3.4-23.4 glibc-locale-2.3.4-23.4 glibc-info-2.3.4-23.4 glibc-html-2.3.4-23 glibc-2.3.4-23.4 glibc-i18ndata-2.3.4-23.4 C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -threaded
On 07 July 2006 11:46, Christian Maeder wrote: Simon Marlow schrieb: The reason we added it to the compiler was so that you could use programs that require -threaded under GHCi. Without it, these programs cannot be used with GHCi. Surely, running user programs is different from just compiling. GHC and GHCi are the same binary. Without -threaded, all FFI calls block the other threads in the program, and this makes it impossible to do lots of things. Obviously, I only want that (my old) sequentiell things are done as reliable (one at a time) as before. And they will be - the threaded RTS only affects FFI calls on multithreaded programs. What version of glibc are you using on Linux? glibc-devel-2.3.4-23.4 glibc-locale-2.3.4-23.4 glibc-info-2.3.4-23.4 glibc-html-2.3.4-23 glibc-2.3.4-23.4 glibc-i18ndata-2.3.4-23.4 I guess that isn't it, I have 2.3.2 here. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
On Fri, 2006-07-07 at 11:28 +0100, Simon Marlow wrote: We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be released without a fix for this. I'm actually quite glad that we've forced this into the open with 6.4.2, otherwise the bug would probably have remained dormant, affecting only those who used -threaded on Sparc. As far as I know this does not affect Sparc Linux, only Sparc Solaris. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
On Fri, Jul 07, 2006 at 11:28:44AM +0100, Simon Marlow wrote: Hi, We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be released without a fix for this. I'm actually quite glad that we've forced this into the open with 6.4.2, otherwise the bug would probably have remained dormant, affecting only those who used -threaded on Sparc. Solaris x86 has similar bugs with the RTS (like mentioned in previous posts). A summary: 6.4 branch from cvs changed the occurrence a bit - it is harder to reproduce it - but possible - and now it segfaults (before - 6.4.2 - it hanged). To try a debug enabled -threaded version of ghc and follow http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes is on my TODO list. Regards Georg Sauthoff pgpr4GbL3eY5d.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threaded runtime error
Volker Stolz wrote: * Volker Stolz [EMAIL PROTECTED]: [EMAIL PROTECTED] [20:17:08] ./timeout 10 /usr/bin/true FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0) A workaround seems to use another threading library here. Both libthr and libc_r work at least for this small example. The error occurs on createOSThread(). I'm not sure where exactly (ie., for the child or the parent, but I guess the child). I'll keep on looking. If you can get me a backtrace, that would be most helpful. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threaded foreign functions calling back.
Peter Strand wrote: Hi, I'd like to use a C-library which calls back into the haskell program, potentially from different threads at the same time. That is, the following calling sequence takes place: (haskell) Calls C via foreign import. (c) Creates threads, which in turn calls back into haskell via foreign exported functions. Is this supported in ghc? Some simple tests suggests that it does work, at least I don't get any crashes, if ghc is compiled with --enable-threaded-rts. But is this intended to work or am I just lucky? Yes, this is indeed what --enable-threaded-rts is intended for. Beware that the code is not well-tested (that's why it's a separate option); however, there are no known bugs (if you encounter any, please tell me). You should also be aware of one remaining problem, which will be fixed in the upcoming GHC 6.2:Your C-library must not rely on the use of thread-local state (that is, pthread_key_create on unix and TlsAlloc on Win32); basically, when you call a foreign import, you don't know in what thread it will be executed (there's some interthread messaging and some black magic going on here). For the same reason, the value of errno cannot be reliably accessed from Haskell with GHC 6.0. Most libraries are entirely unaffected by this problem, but I thought I'd warn you just in case. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: threaded-rts
We have a New Plan for the threaded RTS, which is stable, I think. Wolfgang Thaller is going to (a) write it up (or, rather, tidy up the existing design sketches) and (b) implement it in GHC (which is mostly done). But he's been busy recently. I'm sure that a chorus of hungry users would encourage him! The main thing the New Plan covers is the idea of a bound thread, so that you can guarantee which OS thread will perform a foreign call; I think the lack of this guarantee is what breaks HOpenGL at the moment. The idea is that threaded-rts would be the default. I'm not sure it's worth making a threaded-rts variant distribution right now, given that we'd just throw it away later. But you're welcome to try. Wolfgang, do you have a timescale in mind? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Ian Lynagh | Sent: 22 July 2003 18:35 | To: [EMAIL PROTECTED] | Subject: threaded-rts | | | Hi all, | | I've had a request for --enable-threaded-rts support in the Debian | packages, but I don't want to just build with it as then HOpenGL can't | be used. | | My hope was that I could share most files and just have a different | binary or something for the threaded-rts (it would be even better if a | threaded-rts enabled binary could have it disabled by a +RTS flag, but I | don't think this is possible?). | | However, various .hi, .a files and HSrts.o also seem to differ. So is | the best way forward to create two completely separate packages? | | | Thanks | Ian | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threaded-rts
I'm not sure it's worth making a threaded-rts variant distribution right now, given that we'd just throw it away later. But you're welcome to try. We might not need the variant business when the new threaded-rts is finished, but personally, I like the thought of getting the Threaded RTS classic out there so it gets tested a little more. The new bound threads variant will share a lot of code with the classic variant, so testing the old code a little more does make sense. Wolfgang, do you have a timescale in mind? Well, let's see. I got my Powerbook back from repairs yesterday; now I have to track down one Mac-specific issue for 6.0.1. Then I'll have a look at the head and my old bound-threads prototypes. I might have some (preliminary, experimental, hackish, untested, ugly) patches ready on the weekend. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threaded-rts
On Wednesday, July 23, 2003, at 05:43 AM, Wolfgang Thaller wrote: Well, let's see. I got my Powerbook back from repairs yesterday; now I have to track down one Mac-specific issue for 6.0.1. Then I'll have a look at the head and my old bound-threads prototypes. I might have some (preliminary, experimental, hackish, untested, ugly) patches ready on the weekend. Cheers, Wolfgang Hi Wolfgang, I built the cvs version of 6.0.1 on Sunday (the 20th of July) and had the linker problem mentioned by Axel Simon (symbol _Main_zdmain_closure undefined). The build platform was OS X 10.2.6. If this isn't the OS X bug you're working on let me know. I should have a chance to look into it more deeply over the weekend. Otherwise, send a note when you have something you would like tested. I'm getting much better at building the ghc on my powerbook. ;-) Best Wishes, Greg ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threaded-rts
That, along with your HSrts.o later, ties in with the files that change file size except that /usr/lib/ghc-6.0/package.conf gains a pthread in the rts extra libraries. Ah yes, I overlooked that, because it doesn't happen on Mac OS X :-). It looks like I want to make a package-threaded.conf that thinks the rts package is 'hs_libraries = [HSrts-threaded],' which I install into the same directory [...] Something like that, I guess. As for the .hi files... no idea why they should be different, the configure flag absolutely positively doesn't affect how the libraries are built - do the hi files perhaps contain a timestamp or something else that might change on its own? Could be - looking at one of the .a files at random (libHSposix.a) it looks like it is the timestamps of the files inside it that has changed. FWIW the .hi differences on /usr/lib/ghc-6.0/imports/GHC/Int.hi are: (again chosen at random) (note that these are not contiguous) I don't see anything here. One more thing - is there an easy way to check to see if it has worked? I assume a Haskell program can't tell whether or not it is being run in a threaded-rts? I have access to a dual-CPU machine so I can time things with and without if that makes sense. Dual-CPU doesn't help, as the threaded RTS still only runs one Haskell thread at a time (SMP is a lot harder). However, import Foreign foreign import ccall sleep :: Int - IO () -- slightly wrong signature, but still works :-) main = do forkIO $ sequence_ $ repeat $ putStrLn Hello, world. sleep 10 If the above program prints Hello, world. like mad for 10 seconds, it's the threaded RTS; if it prints it at most a few times and then stops for 10 seconds, it's the non-threaded RTS. Hope that helps, Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
