Escuse me, the module export list was meant to be > module Communicate(runExpect, runSend) where
Facundo On Tue, Jan 28, 2014 at 5:13 PM, Facundo Domínguez <facundo.doming...@tweag.io> wrote: > Hello Carter, > Thanks for the links. IIUC the ObjLink module contains an interface > to the RTS linker. The points raised by Mathieu in his last email as > (1a), (1b) and (2) still hold. > > Here's a use case for (2): > > module Communicate(run) > > import Control.Distributed.Process > > f :: Int -> Int > f = id > > runSend :: Process () > runSend = send someone (static f) > > runExpect :: Int -> Process Int > runExpect n = fmap (($ n) . unstatic) expect > > If any program tries to use runExpect, it would fail at runtime > because it would fail to find `f`, because `f` is not exported and > therefore a symbol for it would not appear in object files. > > The solution that modifies the compiler is superior to all workarounds > we could think of to workaround this problem with a library. Any > suggestions? > > Best, > Facundo > > On Tue, Jan 28, 2014 at 3:03 PM, Carter Schonwald > <carter.schonw...@gmail.com> wrote: >> Theres actually a missing piece of information in this thread: what are the >> example computations that are being sent? >> My understanding is that erlang has not way to send file handles, shared >> variables, Tvars, Mvars, memory mapped binary files, GPU code / memory >> pointers , and other fun unportable things between nodes, and I don't really >> expect / see how we can hope to sanely do that in haskell! >> >> point in fact, even when restricted to "exactly the same binary, running on >> a cluster of homogeneous machines with the exact same hardware, with a >> modern linux distro " you hit some gnarly problems doing this for arbitrary >> closures! Its for a very simple (and fun) reason: address randomization! >> >> Nathan Howell was actually doing some experimentation with one strategy for >> this special case here https://github.com/alphaHeavy/vacuum-tube as a >> deeply rts twiddling bit of hackery so you could in fact "serialize >> arbitrary closures" between homogeneous machines running the exact same code >> (and with address randomization disabled too i think) >> >> on the GHC API front, >> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html >> along with (and more appropriately >> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html >> ) should actually give enough basic tooling to make this possible as a >> userland library, mind you unload was recently fixed up in HEAD by Simon >> Marlow to support the dynamic code loading / unloading use case he has in >> facebook. Point being the GHC 7.8 version of the ObjLink api should >> actually give enough support tooling to prototype this idea in user land, >> and that plus better support for writing "direct haskell code" and getting >> out both a local computation and an AST we can serialize would probably be a >> good set of primitives for making this feasible in user land. I >> >> The meat of my point is 1) "yes I want this too" but also 2) one thing I >> really have come to appreciate about how GHC is engineered is a lot of work >> is done to provide the "right" primitives so that really really great tools >> can be built in user land. I think That the goal of this proposal can be >> accomplished quite nicely with the ObjLink module, unless i'm not >> understanding something. In Fact, because in general not every computation >> will be properly serializable, you need not even bother with tracking an >> explicit symbol table on each side, just try to load it at a given type and >> if it fails it wasn't there! >> >> The point being, linkers are a thing, ghc exposes an API for linking, have >> you tried that api? >> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html >> >> >> >> >> >> >> On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery <allber...@gmail.com> >> wrote: >>> >>> On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug <m...@tweag.io> wrote: >>>> >>>> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald >>>> <carter.schonw...@gmail.com> wrote: >>>> > 1) you should (once 7.8 is out) evaluate how far you can push your >>>> > ideas wrt >>>> > dynamic loading as a user land library. >>>> > If you can't make it work as a library and can demonstrate why (or how >>>> > even >>>> > though it works its not quite satisfactory), thats signals something! >>>> >>>> Signals what? >>> >>> >>> That there is a shortcoming in ghc and/or the rts that needs to be >>> addressed. >>> >>> -- >>> brandon s allbery kf8nh sine nomine >>> associates >>> allber...@gmail.com >>> ballb...@sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
