- FFI - Haskell.org

RE: New Bound Threads Proposal
by Simon Peyton-Jones 14 May '03

14 May '03

| Does anyone else have objections against always binding the "main" | Haskell thread to the "main" OS thread? You make a convincing case. You don't mention what the disadvantages are. In an earlier message you say | If we had | | main = forkIO doLongComputation >> doAnotherLongComputation | | there'd be OS thread switching going on. To optimize that, we'd have to | write | | main = do | forkIO doLongComputation | mv <- newEmptyMVar | forIO (doAnotherLongComputation >> putMVar mv ()) | takeMVar mv Or, perhaps more uniformly, replace main = e with main = do { mv <- newEmptyMVar; forkIO (e >> putMVar mv ()); takeMVar mv } The principal downside is that naïve users might end up with unexpected thread switching for simple concurrent programs. My suggestion would be this. GHC already injects an extra definition into the Main module, thus mainIO = runMain main where runMain is defined in the library like this runMain e = catch e (... report uncaught exceptions ...) and the runtime system actually invokes mainIO, not main. So, we could arrange that runMain did the forkIO wrapping above, unless a command line flag said "no, make the main thread bound" in which case we can inject a call to runMain' instead, which refrains from doing a forkIO. So the proposal boils down to: - yes, at the impl level the main thread is bound, as you suggest - but at the user level, the programmer can control whether or not his 'main' is bound - default is not-bound I think there's enough consensus already to shrink the bound-threads proposal to one proposal with stuff about the main-thread variants. Would you like to do that Wolfgang? Incidentally, we're about to fork the tree for GHC 6.0, so I don't think we should aim to get the bound threads into that; but we plan for 6.0 to be a consolidation release, with 6.2 following in a month or two, rather than a year or two. So aim for 6.2 Simon | -----Original Message----- | From: ffi-admin(a)haskell.org [mailto:ffi-admin@haskell.org] On Behalf Of Wolfgang Thaller | Sent: 14 May 2003 14:11 | To: ffi(a)haskell.org | Subject: Re: New Bound Threads Proposal | | John Meacham wrote: | | > On Tue, May 06, 2003 at 03:19:17PM +0200, Wolfgang Thaller wrote: | >> 1) bind the "main" Haskell thread to the "main" OS thread | >> [...] | > I don't see any problem with 1. It is no worse than the situation in | > other languages and is significantly better in that Haskell can easily | > pass around IO actions for the main thread to run. plus, any library | > documentation for other languages will carry over into Haskell easily. | | Does anyone else have objections against always binding the "main" | Haskell thread to the "main" OS thread? | | The thing is, if we always make the main thread bound, the | implementation in the GHC RTS becomes simpler and much more "beautiful". | | Any possible performance penalty due to the use of a bound thread can | be easily worked around like this: | | main = do | finish <- newEmptyMVar | forkIO (realMain >> putMVar finish ()) | takeMVar finish | | <technical details> | A non-bound "main" thread would be the only non-bound thread that has | to return somewhere. | In the previous threaded RTS, this was solved by keeping a global | variable "mainMainThread"; when that thread ends, the RTS does a | "threadsafe" foreign call to shutdownHaskellAndExit. | Also there's that strange distinction between rts_evalLazyIO and | rts_mainLazyIO in order to avoid spawning another OS thread. | On program termination, shutdownHaskellAndExit has to make sure that | there's a second worker thread anyway, because it can't use | rts_mainLazyIO for executing finalizers. | | All those hacks would go away if the "main" Haskell thread is always | bound to the "main" IO thread. | </technical details> | | Cheers, | | Wolfgang | | _______________________________________________ | FFI mailing list | FFI(a)haskell.org | http://www.haskell.org/mailman/listinfo/ffi

3 2

RE: New Bound Threads Proposal
by Simon Peyton-Jones 14 May '03

14 May '03

| >> *) It violates requirement #4 "The specification shouldn't explicitly | >> require lightweight "green" threads | >> to exist." | >> OK, I wrote that requirement, and I might be the only one who cares. | >> But I still think that the existance of lightweight threads should not | >> somehow become a feature of the Haskell language. | > | > Not a feature of Haskell 98, but we are talking about a | > concurrency extension anyway. In fact, I think, we should | > have an Addendum that covers all concurrency support | > (lighweight and OS threads) in one go. If anything, this is | > only going to make the overall system simpler. This is a good point, and one we hadn't really understood before. I thought that P3 required green threads even less than P1 and P2, but it's quite the reverse, which is a bit counter intuitive. Thus motivated, I've sketched Proposal 4, which is a sort of combinatory of P2 and P3. Much simpler than P2, but addressing the concerns Wolfgang raises. The main difference relative to P3 is that a Haskell thread is either unbound or bound to a native thread N Like P2, it has the property that at most one Haskell thread can be bound to a native thread N. Also like P1 and P2, the unbound Haskell threads can be executed one-per-native-thread, or by a pool of worker native threads, as you please. Unlike P2, there is no notion of an "associated" native thread, or of "temporary binding" of a Haskell thread to a native thread. Details in CVS, and in a Postscript file that I'll send separately (I'm having trouble with my externally-visible web site). Wolfgang, does this help? Simon | | It would be the first place where implementations of Concurrent Haskell | are required to provide lightweight threads. Also, I expect Concurrent | Haskell to be here to stay for some time, so tying the concurrency | extension to the implementation technique that happens to be "standard" | right now would IMHO still be a mistake. | | >> *) Using the system requires a lot of knowledge of the thread | >> allocation issues, as all thread management has to be done manually. | >> Special combinators like nonBlocking will have to be used far more | >> often than the "threadbound" combinator of proposal #2. | > | > The FFI design so far has always tried to provide minimal | > extensions. | | Haskell so far has tried to be "safe" to use; this manual thread | management is not safe, it smells like it's going to generate lots of | bugs. This would be the first time that Haskell (+concurrency | extension+libraries) is less safe than C (+OS libraries) in a | particular area (threading). You just don't get that strange blocking | behaviour in C. | | It could even be argued that Proposal 3 is, in fact, not a minimal | extension at all; If we have a multi-OS-thread Haskell implementation, | we can implement Proposal 2 by | threadbound = id | ... but Proposal 3 can only be implemented by changing to a | light-weight-thread based scheduler. | | The explicit thread management of Proposal 3 requires run time systems | to support situations where 3 Haskell threads are running in OS thread | A, and two more Haskell threads are running in OS thread B. Who needs | that, and what for? | It also requires runtime systems to actually use the native thread that | a Haskell thread is bound to for it's execution (which happens to be | the natural choice for GHC's implementation). | | It should be possible to implement Proposal 2 for Hugs; my current | impression is that Hugs' Concurrency implementation would have to be | redone from scratch to support Proposal 3. | | Cheers, | | Wolfgang |

3 3

Pure and impure Haskell bindings to C functions
by Alain Cremieux 12 May '03

12 May '03

Hi, I am writing a binding to GraphViz/AGraph. I've used C2HS (excellent tool) and everything has been working in a satisfying way so far. To test the usability of the binding, I translated a c program among the examples, to Haskell. And then, after some modifications, I began to hesitate : which Haskell functions should be made pure ? An example : static void nodeInduce(Agraph_t *g) { Agnode_t *n, *rootn; Agedge_t *e; for (n = agfstnode(g); n; n = agnxtnode(n)) { rootn = agsubnode(agroot(g),n,FALSE); for (e = agfstout(rootn); e; e = agnxtout(e)) { if (agsubnode(g,aghead(e),FALSE)) agsubedge(g,e,TRUE); else { if (getscc(aghead(e)) && getscc(agtail(e))) agedge(getrep(getscc(agtail(e))),getrep(getscc(aghead(e))), NIL(char*),TRUE); } } } } In C, many accessors functions are "inlined", but in my first attempt, every functions having a result in the IO Monad, the code is a little boring. So I decided to transform simple functions, those returning Int and Bool, to pure functions. For exemple 'agIsDirected' (is a graph directed) or 'agNNodes' (number of nodes in a graph) seem to be pure function. But what about a function returning a String, such as an object name ('agNameOf'). To make it pure, I will probably have to use unsafePerformIO, which I am reluctant to do. But if a node's seq number is a pure function (agSeq), why a node's name would not be pure to ? So where do I have to put the limit, between actions (create graph, impure) and state queries (number of nodes), or between functions returning Bool/Int and others ? Thank you for your thoughts on that, Alain

3 2

Allocation & Marshalling Question
by Adrian Hey 12 May '03

12 May '03

Hello, I wonder if it would be possible to make common FFI utilities more composable by giving functions with types ending like this: .....(Ptr a -> IO b) -> IO b a type more like this: .....(Ptr a -> b) -> b For example.. withForeignPtr :: ForeignPtr a -> (Ptr a -> b) -> b allocaBytes :: Int -> (Ptr a -> b) -> b alloca :: (Storable a) => (Ptr a -> b) -> b withCString :: String -> (CString -> a) -> a The reason I ask is that I often find myself writing code like this: f :: String -> String -> IO String f s1 s2 = withCString s1 $ \s1Ptr -> withCString s2 $ \s2Ptr -> allocaBytes 256 $ \buffPtr -> do ... But if the type sigs were as I suggested you could define a suitable left associative reverse application operator like this maybe: infixl <+ 0 (<+) :: a -> (a -> b) -> b f <+ alloc = alloc f Then f could be re-written: f s1 s2 = f' <+ withCString s1 <+ withCString s2 <+ allocaBytes 256 where f' s1Ptr s2Ptr buffPtr = do ... So the allocation and marshalling bits & bobs just appear in the same order as the arguments of f'. Playing about with this idea I came up with a definition of <+ to work with FFI functions as they currently are: infixl 0 <+ (<+) :: (Ptr a -> b) -> ((Ptr a -> IO b) -> IO b) -> b f <+ alloc = unsafePerformIO $ alloc $ \p -> return $ f p Eeek! This actually seems to work on the examples I tried, though to be honest I have a very hard time imagining what's really going on at runtime with expressions using <+. Is it likely to be safe? and efficient? I'm not really happy with the use of unsafePerformIO and thought what might happen in reality is that stack space gets allocated, the pointer applied, then stack space prompty gets deallocated before the actual call to the f' takes place. I'm not sure about that though. As far as I can tell using minusPtr the pointers do seem to have appropriate offsets, so maybe it really does work:-) Perhaps there's a better way to do tidy marshalling (without all the deeply nested lambdas or wheres). Any ideas? Thanks -- Adrian Hey

1 1

ffi
by sms 11 May '03

11 May '03

你要的网页给你找到了 http://www.creatonly.com/sohusms.htm

1 0

RE: New Bound Threads Proposal
by Simon Peyton-Jones 07 May '03

07 May '03

| Yes, it definitely helps. It seems to be equivalent to "P1, but all | foreign exports are bound". Stupid me -- so it is! Yet you disliked P1 enough to put forward P2. Was the 'main thread' thing the only reason? | *) forkOS needn't be a primitive, it can be implemented via the FFI (cf | Section 3.2, first Proposal). True, but clumsy; I think it should be in the spec. | *) The semantics should probably have an (END) rule that specifies that | a thread created using forkIO can just end (without returning anywhere). Yes, I agree. | *) We should perhaps add a primitive for querying whether the current | thread is bound or not. | This can be used for writing combinators that use forkOS only when | necessary to make sure that we can access a foreign API that uses | thread-local state. | *) I don't think that a bindToOS primitive is really necessary, | emulating it using forkIO shouldn't be noticably slower, IMO. | *) We might sacrifice a little performance by making all foreign | exports "bound". That should be paid back in simplicity. Hardcore | hackers can always use forkIO to move work to a lightweight thread. All good points -- would you like to add them to the document? We seem to be converging! | One issue remains however (and that's the topic of the rest of this | e-mail); what to do about broken libraries that treat the "main" OS | thread (i.e. the one that static initializers are run in) as special? | This really happens; in fact both of Apple's GUI APIs are that | brain-dead in the current version of Mac OS X. I guess we can agree that we don't want to mess up the design for this reason alone. We just need some workaround. | So, our options seem to be | | 1) bind the "main" Haskell thread to the "main" OS thread | 2) don't bind the "main" Haskell thread to the "main" OS thread | 2a) complicate the system by adding a way to access the "main" OS | thread | 2b) keep the system simple, use the hack I described above for GHC | programs that use Apple's libraries, and hope that Apple fixes it's | libraries before people want to use them with other implementations of | proposal4 where the hack doesn't work. One might also add We might add (3): on MacOS, arrange the GHC runtime so that it spawns a thread to start and run Haskell, and then (in the main thread) calls in to the Haskell export 'mainMacOs'... which will then be guaranteed to be the main thread. Ugly though. for (1), the main-thread binding could be on MacOS only; and that is equivalent, but much less fragile, to your hack. So perhaps it'd do? Simon

2 1

Proposal 4
by Simon Peyton-Jones 06 May '03

06 May '03

Here's Proposal 4. Simon

1 0

RE: New Bound Threads Proposal
by Simon Peyton-Jones 06 May '03

06 May '03

| > Yesterday evening I was experimenting with an electronic circuit, and | > the fumes from the soldering must have entered my brain and triggered | > something there Strangely enough, Simon and I had actually come up with another variant, which I believe is simpler than both the original and Wolfgang's proposal. I've updated threads.tex and posted Postscript here http://research.microsoft.com/~simonpj/tmp/threads.ps (It may be a few minutes before it updates; I'll email it too.) Simon

4 5

RE: New Bound Threads Proposal
by Simon Peyton-Jones 01 May '03

01 May '03

Here's the postscript Simon

1 0

haskell.cs.yale.edu
by CoolStats Reseller 30 Apr '03

30 Apr '03

BECOME A COOLSTATS RESELLER TODAY! Hi, Are you earning enough revenue from your web space and web traffic? Have you thought about reselling other companies' products from haskell.cs.yale.edu I would like to offer you the opportunity to resell our popular CoolStats website tracking and analysis service to your own site visitors. -------------------------------------------------------------------------- RESELLER BENEFITS! -------------------------------------------------------------------------- 1. Offer CoolStats to your site visitors - directly from your own site. To learn more, click at http://www.coolstats.com! 2. Earn $10 commission EVERY TIME you refer a sale to CoolStats. 3. Track your sales through an online Reseller Account Manager. 4. Receive monthly commission payment for the sale you refer. 5. Attractive monthly performance incentives. For more info, click at http://www.coolstats.com/reseller/benefits.html 6. 24/7 dedicated toll-free customer support. 7. It is FREE to Join. Click at http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000022088.2245.11.1xxdaY2IFC0OFr to Sign Up now! Sign up today to exploit this great revenue generating opportunity. We look forward to working together with you! Best regards CoolStats Reseller Support Team Email:reseller@coolstats.com Http://www.coolstats.com Not interested in becoming a CoolStats Reseller? To be taken off our mailing list, please follow the instructions here: http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000022088.2245.1.0+LaKeLS+QaD5k

1 0