Re: Native Threads in the RTS
Dean Herrington wrote: [...] Rather, I find it nonintuitive that calling from Haskell to foreign code and back into Haskell should create a new Haskell thread, when these two Haskell threads really are just different portions of a single "thread of computation" (deliberately vague term). I agree to that. Creating a new thread for calling back into Haskell _only_ makes sense if you look at it from inside the GHC RTS. Before I had a look at the relevant parts of the RTS, I would never have thought of that. I don't know if there's any advantage/disadvantage to changing GHC's internals. The only _observable_ difference is the thread's ThreadIds, and this should at least be clearly documented (or, even better, it should be "explicitly undocumented", so that no one will be suprised if the behaviour is changed in the future). Off the top of my head I can think of two situations in which having separate threads is bothersome. 3. Throwing exceptions to a thread If I manually translate haskell exceptions to foreign exceptions and back, there is no reason why I shouldn't want to raise an exception in a thread I have a threadId for, even if that thread called a foreign function which in turn called back to haskell. I think that the behaviour can always be emulated using MVars however, so I think there's no immediate action required. --- I've tried to rephrase my proposal for native threads, this time treating GHC's behaviour in this situation as an implementation detail. I think the meaning of the proposal becomes clearer because of this. The proposal doesn't comment on ThreadIds, so the non-intuitive (IMHO) behaviour in GHC is independent of the "bound threads" proposal. I think I've understood both my own specification and the current RTS well enough to start trying to implement a prototype soon. The intended meaning of the specification hasn't changed for the third revision in a row. Does anyone have concrete suggestions for the syntax change to foreign export and foreign import "wrapper"? Cheers, Wolfgang = Bound Threads Proposal, version 5 Goals ~ Since foreign libraries sometimes exploit thread local state, it is necessary to provide some control over which thread is used to execute foreign code. In particular, it is important that 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. This specification is intended to be implementable both by multithreaded Haskell implementations and by single-threaded implementations and so it does not comment on which particular OS thread is used to execute Haskell code. Definitions ~~~ A native thread is a thread as defined by the operating system. 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. When a Haskell thread calls a foreign imported function, it is not considered to be blocked (in the GHC runtime system, the calling thread is blocked; This is considered an implementation detail for the purposes of this specification, but be aware that myThreadId might return several different values for one "Haskell thread" as defined here). If the foreign function calls back to Haskell, the callback is said to run in the same Haskell thread. Design ~~ Haskell threads may be associated at thread creation time with either zero or one native threads. Each Native thread is associated with at most one Haskell thread. A native thread that is associated with a Haskell thread is called a bound Haskell thread. A Haskell thread that is associated with a native thread is called a bound native thread. A Haskell thread is always executed by a native thread. This specification places absolutely no restrictions on which native thread is used to execute a particular Haskell thread. The Haskell thread need not be associated with the native thread used to execute it, and one Haskell thread may be executed by more than one native thread during its lifetime [but not by several native threads at once]. A bound native thread may not be used for executing any Haskell thread except the one it is bound to. It is implementation dependent whether the main thread, threads created using forkIO and threads created for running finalizers or signal handlers are bound or not. 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 decide which native thread to run the foreign function in. The native thread that is used may not be bound to another Haskell thread. The existing distinc
RE: :info in ghci
I see your point. Though, I wouldn't be averse it it printing fixity for everything. From my point of view, when I do :info on something, I want as much information as possible. ...speaking of which :), would you consider printing the entire datatype when :info is done on a constructor? For instance ':info Nothing' currently just prints: -- Nothing is a data constructor Nothing :: forall a. Maybe a but this really isn't any more information than I get out of ':t Nothing'. It might be nice if it also printed the results of ':info Maybe', so I could see the other constructors. I've run into this many times, most recently when using hSeek, I had code that used hSeek with AbsoluteSeek, and I wanted SeekFromEnd...in order to find this out, I had to either look in the docs (slow), or do two :infos, first on AbsoluteSeek and then on SeekMode... I'm sure opinions differ on this, though... -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Tue, 3 Dec 2002, Simon Marlow wrote: > > Ah...but if the fixity is not explicitly specified (and thus > > defaults to > > infixl 9), this isn't printed, which is what was catching > > me...it seems it > > should be (or perhaps say "infixl 9 (default)")? > > But every variable has a fixity, including normal identifiers... should > we report the default fixity for those too? > > Cheers, > Simon > ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: :info in ghci
> Ah...but if the fixity is not explicitly specified (and thus > defaults to > infixl 9), this isn't printed, which is what was catching > me...it seems it > should be (or perhaps say "infixl 9 (default)")? But every variable has a fixity, including normal identifiers... should we report the default fixity for those too? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: :info in ghci
Ah...but if the fixity is not explicitly specified (and thus defaults to infixl 9), this isn't printed, which is what was catching me...it seems it should be (or perhaps say "infixl 9 (default)")? -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Tue, 3 Dec 2002, Simon Marlow wrote: > > It already does... but a bug meant it wasn't always reporting it. > > > > Now fixed in the head. > > ... and the bug doesn't exist in 5.04.1. > > Cheers, > Simon > ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Native Threads in the RTS
> 2. It seems perfectly reasonable to want to have the Haskell > called-back code throw an exception that is caught by the Haskell code > that called out to foreign code. "Reusing" the Haskell thread is > necessary (though not sufficient) to achieve such behavior. This is a particularly tricky problem, and I prefer to leave it up to the programmer to handle such things. Propagating the exception to the original (Haskell) caller automatically is unlikely to be the right thing to do, because the foreign code will almost certainly want to do some clean up. If the foreign language supports exceptions then it is conceivable that we could turn a Haskell exception into a foreign exception (and vice-versa), but for plain C I think we should leave well alone. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: :info in ghci
> It already does... but a bug meant it wasn't always reporting it. > > Now fixed in the head. ... and the bug doesn't exist in 5.04.1. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Request: suppress specific warnings at specific places
> This doesn't seem to work (easily) for me. I want -Wall applied to > all my source, so give it on the command line. Because the OPTIONS > options get prepended, the -Wall seems to win out. :(. I could add > -Wall at the top of all my source files, but that's unappealing. If > GHC provided a way to have a command-line options appear before the > OPTION options in the final list, that would work. That's odd - it works here. OPTIONS pragmas are supposed to override the command line, and indeed in a small example I just tried I can override individual warnings in the OPTIONS pragmas with -Wall on the command line. Cheers, SImon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Java back end
> 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. There's one in ghc/compiler/javaGen, but it hasn't worked for a long time (and never really worked, as far as I can tell). I think Andy Gill <[EMAIL PROTECTED]> was responsible for that one, you might want to contact him. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 'accept' does not seem to be thread friendly ..
> Below is my sample code ; the Net Cats > This does not work, because 'accept' fuction of the > Network module blocks the whole process, unlike > Haskell Standard IO functions which blocks its thread > only. How did you work around with complex networked > applications ? It would be very helpful if you could > give us more detailed advice from your expierience. > > Network.accept does not seem to be thread friendly. > Then how am I going to keep my server from being blocked > by accept? I'm not sure exactly what your program is supposed to be doing, but as far as I can tell it's working fine :-) While the accept is waiting for a connection, the thread doing the accept has taken the MVar, thus blocking the other thread which is also trying to take the MVar. I think this is perhaps not what you had in mind? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
