Re: tryTakeMVar :: MVar a - IO (Maybe a)

[George Russell]

Simon Marlow wrote:
 The only way I can see to do this is to add a lock field to the MVar.  And
 since this lock would look very much like another MVar, you may as well just
 use another MVar to lock it (after all, that adds exactly zero extra
 complication to the system :-).
Absolutely.
 There's still some discussion to be had on what putMVar should do when
 presented with a full MVar.  The options are
The logical dual to tryTakeMVar would be
   tryPutMVar :: MVar a - a - IO Bool
Or even
   tryPutMVar :: MVar a - IO a - IO (Maybe a)
(the latter only if you can keep the MVar empty while you run the action.)
I have absolutely no need for either of these functions, but would either of
them be implementable without extra expense?

RE: ghc with shared libraries ?

[Ian Jackson]

Simon Marlow writes ("RE: ghc with shared libraries ?"):
 Still can't be done, I'm afraid.  At least for Haskell libraries; you could
 compile parts of the RTS and libHS_cbits shared, but we haven't done that.
 
 This message has more details:
   
 http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg02765.html

I read that message and I'm afraid I'm puzzled.

Do you mean that GHC-compiled Haskell libraries don't have a stable
ABI ?  I can see that that might be true, but it might also be
possible to have a souped-up dynamic linker that could fix things up
(possibly with, as you say in the message, adverse effects on the
sharedness of the library).

But if that's all that the problem is it doesn't explain why even when
exactly the same object files are put together via dynamic linking
instead of just static it doesn't work (as I infer from people's
messages - I haven't tried it).

I was under the impression that at least on sensible platforms like
Linux, the relocation and linking that is done by the dynamic linker
is very similar to that done by the compile-time linker.  In fact, on
Linux you don't even need to compile your code -fpic: without it there
are simply lots more relocations in the resulting object files and
hence in the shared library, and you end up not sharing most of the
text (because the dynamic linker has to edit it when relocating it).
So without -fpic things work, but there's just a performance penalty.

You say:
 ... for example the assumption that  a data object consists of a symbol
 followed by a fixed amount of data, so that certain data objects can be
 copied into the binary's data segment at runtime.  GHC's object files don't
 follow these rules, so can't be made into shared objects easily.

It seems to me that this view of `data object' is simply the
definition of what ought to go into the initialised data segment of
the resulting shared object.  Unix shared libraries don't have a view
about what a `data object' is.

So perhaps this can be solved by putting things in more appropriate
sections and/or making intra-segment references more explicit in some
way so that the right relocation data is put there for the dynamic
linker ?

Ian.