- Glasgow-haskell-users

Re: Native Threads in the RTS
by Wolfgang Thaller 02 Dec '02

02 Dec '02

I've postponed writing up a new proposal again... But I'm going to sum up some requirements that I would like to see fulfilled - to make it clearer to others why I'm proposing such strange things... *) It should be possible for Haskell code to arrange that a sequence of calls to a given library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. *) The specification should be implementable in a way that allows a lot of foreign calls to be made with no additional overhead with respect to GHC's current "unsafe" foreign calls. *) The good performance of the existing lightweight "green" threads in GHC should not be sacrificed. Performance should still OK when using the new features with only a few threads (i.e. not more than commonly used from multithreaded C programs). *) The specification shouldn't explicitly require lightweight "green" threads to exist. The specification should be implementable in a simple and obvious way in haskell systems that always use a 1:1 correspondence between Haskell threads and OS threads. *) The specification shouldn't specify which particular OS thread should be used to execute Haskell code. It should be possible to implement it with e.g. a Haskell interpreter running in one OS thread that just uses other OS threads for foreign calls. *) There should be no unexpected blocking. Especially, threadsafe calls should never cause other threads to block. I'm currently stuck thinking about one particular problem that I discovered in my current version of the spec. What happens when an unbound Haskell thread calls a threadsafe foreign function which in turn calls a bound foreign exported function? Well, I think my current proposal says relatively clearly what's supposed to happen, but I discovered it's not as easy to fit that in the current implementation of GHC as I thought... in fact it might be quite difficult. I'll have to do more thinking before I can be sure, though. That's it for today, Regards, Wolfgang

1 0

RE: :info in ghci
by Simon Peyton-Jones 02 Dec '02

02 Dec '02

It already does... but a bug meant it wasn't always reporting it. Now fixed in the head. SImon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 02 December 2002 16:50 | To: GHC Users Mailing List | Subject: :info in ghci | | Any chance :info could also report fixity information, especially for | symbolic identifiers? | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

:info in ghci
by Hal Daume III 02 Dec '02

02 Dec '02

Any chance :info could also report fixity information, especially for symbolic identifiers? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Java back end
by Mark Carroll 02 Dec '02

02 Dec '02

I was wondering, what happened to the Java back end that was going to produce bytecode - how's it going? Is it now at all available? I'm having some difficulty finding it, and it sounded interesting. -- Mark

1 0

help for "Killed"
by Dean Herington 02 Dec '02

02 Dec '02

I have a program that dies, saying simply "Killed". How can I tell what that means? I presume the program is suffering a ThreadKilled exception, and I guess it may be due to stack or heap overflow. (The program is processing a 50MB file.) Profiling, even with -xc, yields no information. Dean

2 1

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

02 Dec '02

| 2. Calling from foreign code into Haskell to a bound foreign import will | require some special handling to ensure that a subsequent call out to | foreign code will use the same native thread. Why couldn't this special | handling select the same Haskell thread instead of creating a new one? This is just an efficiency issue, right? If creating a Haskell thread from scratch is very cheap, then it's easier to do that each time rather than to try to find the carcass of a completed Haskell thread. If you do the latter, you need to get into carcass management. But maybe there is more to it than efficiency in your mind? Simon

1 0

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

02 Dec '02

Improving. Want to put it in CVS? Simon M can suggest where. Simon | Definitions | ~~~~~~~~~~~ | A native thread (aka OS thread) is a thread as defined by the operating | system. | A Haskell thread is [*** FIXME - How shall I put this? ***] the thing | you see from Haskell land. A "Haskell thread" encapsulates the execution of a Haskell I/O action. A Haskell thread is created by forkIO, and dies when the I/O action completes. A Haskell thread is always executed by a native thread. The Haskell RTS creates one or more "worker native threads" to execute Haskell threads. | Haskell threads may be associated at thread creation time with either | zero or one native threads. Each Native thread is associated with zero | or more native threads. zero or more *Haskell* threads. Can you give an example of when a native thread is associated with more than one Haskell thread? To avoid "A Haskell thread associated with a native thread" I'd prefer to define the term "a bound Haskell thread". I would also like to describe a "bound native thread" as one that has associated Haskell thread(s). | If a native thread is associated with one or more Haskell threads, | exactly one of the following must be true: | *) Exactly one Haskell thread associated with the native thread is | executing. | *) The native thread is executing foreign code. | *) The native thread and all Haskell threads associated with it are | blocked. You don't say (but you do mean) A bound Haskell thread can be executed only by its associated native thread You don't say (and I'm not sure if you mean) If a bound native thread blocks, all of its associated Haskell threads are blocked too If a bound Haskell thread blocks, its associate native thread and all its associated Haskell threads also block. | The thread that main runs in, threads created using forkIO and threads | created for running finalizers or signal handlers are not necessarily | associated with a native thread. However, an implementation might | choose to do so. But the impl may *not* choose a bound native thread. These must be kept inviolate. | When a "free" foreign exported function is invoked, the implementation | may freely choose what kind of Haskell thread the function is executed | in. It is not specified whether this thread is associated with a | particular OS thread or not. Again, it must not be a bound native thread. | When a foreign imported function is invoked [by Haskell code], the | foreign code is executed in the native thread associated with the | current Haskell thread, if an association exists. If the current | Haskell thread is not associated to a native thread, the implementation | may freely decide which thread to run the foreign function in. | The existing distinction between unsafe, safe and threadsafe calls | remains unchanged. If a bound Haskell thread calls a foreign import that is not labelled 'threadsafe' which calls a bound foreign export does that work? What if the foreign export was not bound? Similarly, if the foreign import was labelled 'threadsafe', would it work? It's not obvious to me. Some kind of semantics would be good.

4 3

RE: Request: suppress specific warnings at specific places
by Simon Marlow 02 Dec '02

02 Dec '02

> GHC's excellent warnings are very helpful. They would be somewhat > more so if it were possible to suppress a warning about a specific bit > of code. One possible syntax (to which I gave no commitment) would be > > {-# WOFF "non-exhaustive pattern matches" #-} > <offending code> > {-# WON "non-exhaustive pattern matches" #-} > > . Another would be > > {-# WOFF 523 #-} > <offending code> > {-# WON 523 #-} > > where 523 is a warning number emitted with the warning message. > > This would be particularly useful with the recently granted wish for > -Werror. This would be nice, but it would be tricky to implement: declarations have to be tagged with a list of "exceptions" to the prevailing warning settings. I doubt we'll do this any time soon, but patches are welcome as usual... (of course, the workaround is to put the offending code into a module of its own, and use OPTIONS to turn off the appropriate warnings). Cheers, SImon

2 2

5.04.1 on OS X
by Nicolas.Oury 01 Dec '02

01 Dec '02

Hello, is there a binary distribution for Mac OS x of GHC 5.04.1? Best regards, Nicolas Oury

1 0

Calling haskell DLL from MSVC++
by Mauricio Carvalho 01 Dec '02

01 Dec '02

Hey! I' having problems to call functions from a DLL made with ghc with a C++ program, using Microsofts Visual C++ To learn how to do it, I tried the example found at the user's guide (11.3, 11.4), but things aren't working out.. Here is as far as I've done: I have a haskell module, MyModule.hs:module MyModule where foreign export stdcall fac :: Int -> Int fac :: Int -> Int fac n | n <= 0 = 1 | otherwise = n * fac(n-1) I compile it with: ghc -c MyModule.hs -fffi The .c file, containing the DLL initialization is: #include <windows.h> #include <Rts.h> extern void __stginit_MyModule(void); static char *args[] = {"MyDll", NULL}; BOOL STDCALL DllMain(HANDLE hModule, DWORD reason, void *reserved){ int i; if(reason == DLL_PROCESS_ATTACH){ printf("\nStarting Haskell"); startupHaskell(1, args, __stginit_MyModule); printf("Haskell Started!!"); return TRUE; } return TRUE; } Which I compile with: ghc -c MyDll.c I build the DLL with: ghc --mk-dll -o MyDll.dll MyModule.o MyModule_stub.o MyDll.o The DLL is build, and following the example, I try to call it from VB, but the program hangs. I don't know if I'm missing something in the building process, I can't see what it can be. Moreover, for calling it from my C++ programs, I need a library file (generally called .lib in MSVC linker, I think it's equivalent to the libMyLib.a of gcc) to resolve the function (fac) when linking. I tried to use dlltool -b MyDll.dll -l MyDll.lib to contruct the .lib file, it's contructed, but yet, when I use to link my C++ program with the DLL, i got unresolved external symbol for the function. Thus, I can't even link the C++ program. Note that I used the stdcall (for fac)to follow the example; I tried even with ccall, but without success either. Can someone see if I'm missing something at the creation process of the dll? And to create the library file, is it the right thing to do? Mauricio

1 0