Sven Panne <[EMAIL PROTECTED]> writes:
>
[...]
>
> Aaaah! *lights going on* But then I suggest that foreign export
> dynamic should be changed to return a stable pointer instead
> of an Addr. This shouldn't break too much code, because both
> are CCallable.
>
I don't see the need, since
Dear GHC Gurus ;-)
Michael Hobbs <[EMAIL PROTECTED]> and I were just discussing
the use of GHC's threads (ie, the `Concurrent' library)
within GTK+ applications when we came across an
inconsistency between ``The STG runtime system (revised)''
and the actual implementation of the RTS in GHC 4.02.
Simon Peyton-Jones wrote:
> Yes, we do this a lot. It's such a useful thing that I wonder
> whether we should support it more directly, somehow.
That eases my mind. :-) I feared that I'm the only one doing this
kind of hackery...
> As it stands, its vulnerable to 'blockingSem' getting inlin
> I'm not sure if this is neccessary, because it is possible to have
> global (mutable!) variables via IORefs + unsafePerformIO:
>
> blockingSem :: IORef QSem
> blockingSem = unsafePerformIO (newIORef =<< newQSem 1)
>
> gtkMumbleFooBar :: ... -> IO ()
> gtkMumbleFooBar ... = do
>...
>wai
"Manuel M. T. Chakravarty" wrote:
> [...]
> The required synchronization could of course be programmed
> using `Concurrent's semaphores, but with the disadvantage
> that if we want to provide this thread-safety transparently
> for user applications in a library, we have to define a
> "new" IO mona
> Michael Hobbs <[EMAIL PROTECTED]> and I were just discussing
> the use of GHC's threads (ie, the `Concurrent' library)
> within GTK+ applications when we came across an
> inconsistency between ``The STG runtime system (revised)''
> and the actual implementation of the RTS in GHC 4.02. The
> sp
"Manuel M. T. Chakravarty" wrote:
> [...]
>The specification says in Section 4.6 (about "safe" and "unsafe"
> C calls) that in case of a "safe" call, a new OS thread is
> spawned to execute the called C
As I understand, it's fine to run them in new OS thread , because safe
functions should be pur
> That's what you get with unsafePerformIO; we've even
> added a {-# NOINLINE blockingSem #-} pragma for exactly this reason.
> (Doubtless undocumented.)
ahem. Quote from the 4.02 documentation at
http://research.microsoft.com/users/t-simonm/ghc/Docs/latest/users_guide/use
rs_guide-4.html#ss4.2
> Yes, we do this a lot. It's such a useful thing
> that I wonder whether we should support it more directly,
> somehow. As it stands, its vulnerable to 'blockingSem'
> getting inlined at its usage sites, which would be a total
> disaster. That's what you get with unsafePerformIO; we've even
>
> One other thing: since unsafePerformIO already has a NOINLINE
> pragma on it,
> I don't think it's necessary to explicitly NOINLINE all these
> top-level
> mutable thingies.
Oh yes it is:
foo :: IORef Int
foo = unsafePerformIO (newIORef 0)
baz :: IO Int
baz = do { v <- readIORef foo;
> "Manuel M. T. Chakravarty" wrote:
> > [...]
> >The specification says in Section 4.6 (about "safe" and "unsafe"
> > C calls) that in case of a "safe" call, a new OS thread is
> > spawned to execute the called C
>
> As I understand, it's fine to run them in new OS thread , because safe
> functio
To follow up on Sergey's suggestion a while back,
let's keep this within Haskell98 realms and use
{-# notInline ... #-}
instead. (This is not supported in 4.02, but
ghc-current has got it).
--sigbjorn
> Simon Marlow [mailto:[EMAIL PROTECTED]] writes:
>
>
> > That's what you get with unsa
> Let's summarize the questions:
>
> * Will safe FFI calls eventually be executed by extra OS
> threads?
> * Would you support additional synchronization primitives in
> the RTS (and `Concurrent') to support making the use of
> libraries like GTK+ thread-safe?
> * How about three kinds of
13 matches
Mail list logo
