RE: Native Threads in the RTS
| 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Silly question about IORefs and MVars
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Native Threads in the RTS
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Class/Implicit Param/Module Interface bug
These bugs are now fixed in the HEAD. I hope the fixes will make it
into 5.04.2 as well.
Thanks for identifying them. It was all horribly bogus before.
Simon
| -Original Message-
| From: Ashley Yakeley [mailto:[EMAIL PROTECTED]]
| Sent: 13 November 2002 13:46
| To: Simon Peyton-Jones
| Cc: GHC List
| Subject: Re: Class/Implicit Param/Module Interface bug
|
| Actually it's worse than that. This crashes:
|
| module Main where
| {
| import A;
|
| main = let {?p=test} in putStrLn f; -- BUG: this crashes
| --main = let {?p=test} in putStrLn g; -- this works
| }
|
|
| --
| Ashley Yakeley, Seattle WA
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: first stab at -ffunction-sections
On Mon, Nov 18, 2002 at 11:55:27AM -, Simon Marlow wrote: 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). Trying to garbage-collect unused functions to reduce the size of the .text section. Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug? [was: Implicit params]
Now fixed in the HEAD, and will be in 5.04.2 Thanks for pointing it out. Simon Thanks :) J.A. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: first stab at -ffunction-sections
On Mon, Nov 18, 2002 at 11:55:27AM -, Simon Marlow wrote: 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). Trying to garbage-collect unused functions to reduce the size of the .text section. You should be aware that -split-objs (the trick we use to build our libraries in lots of little bits) gets most of the benefit that you'd get from using -ffunction-sections. You might get slightly more fine-grained discarding of code with -ffunction-sections, but the effect won't be dramatic (I'm guessing). Also there's the issues of telling the garbage collector and the mangler about it. However, it would be nice to be able to use -ffunction-sections/--gc-sections instead of -split-objs. It's been at the back of my mind to have a go at this someday... Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unsafePerformIO and IORefs
I want to write something like
type State a = IORef a
newState :: a - State a
newState v = unsafePerformIO (newIORef v)
But I don't want the compileer to inline this nor to inline any
application of this.
{#NOINLINE newState#}
But how can I stop this function to be inlined when applied for example :
let x = newState 0 in
{... code where x is used twice ...}
How to be sure that x isn't inlined and that all occurences of x are
pointing to the same memory place ?
Best regards,
Nicolas Oury
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO and IORefs
Hal Daume III wrote:
You can't. [...]
Well, you can, but only for CAFs. This idiom/hack is used
quite happily throughout GHC, HOpenGL, H/Direct, ...
Slightly modified stuff from GHC's sources:
-- global variables in Haskell :-)
global :: a - IORef a
global a = unsafePerformIO (newIORef a)
#define GLOBAL_VAR(name,value,ty) \
name :: IORef (ty) ; \
name = global (value) ; \
{-# NOINLINE name #-}
-- examples
GLOBAL_VAR(counter, 0, Int)
GLOBAL_VAR(flag, False, Bool)
Cheers,
S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO and IORefs
On Mon, Nov 18, 2002 at 10:36:05AM -0800, Hal Daume III wrote:
You can't. CSE (common subexpression elimination) will replace any
occurances of 'newState 0' in a function body with the same value.
In short: don't use upIO :)
Sorry, cannot resist to pour a little salt onto the wound :)
[232]% grep global ghc/compiler/utils/Util.lhs
, global
global :: a - IORef a
global a = unsafePerformIO (newIORef a)
[233]%
ghc/compiler/HsVersions.h:
[...]
#ifdef __GLASGOW_HASKELL__
#define GLOBAL_VAR(name,value,ty) \
name = Util.global (value) :: IORef (ty); \
{-# NOINLINE name #-}
#endif
[237]% grep -r GLOBAL_VAR ghc/compiler | wc -l
90
Muahahah... ;-P
Cheers,
Michael
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
