Re: Blocking a task indefinitely in the RTS
> I did try removing this check to see, but it really didn't like that. It > caused GC to be triggered over and over again as the RTS tried desperately > to find something to do, doesn't seem to consider "do nothing" as a valid > state. Oh, I see :( I guess it's not that easy of a fix then. Perhaps the RTS could use a new intrinsic for blocking on foreign state. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Blocking a task indefinitely in the RTS
Okay, I skimmed rts/Schedule.c and now see the problem you mentioned :( > On the non-threaded runtime the timeslice case doesn't apply and you only > have one capability, it will force a GC to try to revive some tasks, and if > at the end of > this the tasks are still blocked it will release one in order to attempt to > proceed. In short, as far as I can tell I don't think it considers > reach-ability at all, not for MVars. Maybe that should be considered a false positive (bug) for the deadlock checker? Just because the Haskell runtime has a single thread, that doesn't imply the whole program is necessarily single-threaded (in the presence of foreign things). I'd think this is a legitimate use case for MVars. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Blocking a task indefinitely in the RTS
Strange, how could the scheduler assume a deadlock if the MVar could be called from a closure that is still alive? Can you show the code that you're testing? On Mon, Jan 7, 2019, at 14:09, Phyx wrote: > Hi Phil, > > Thanks for the reply, however that just gives me a forced deadlock removal > as before. > > new bound thread (1) > cap 0: schedule() > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (blocked on an MVar) > thread1 @ 03205388 is blocked on an MVar @ > 032040c8 (TSO_DIRTY) > deadlocked, forcing major GC... > all threads: > threads on capability 0: > other threads: > thread1 @ 03205388 is blocked on an MVar @ > 032040c8 (TSO_DIRTY) > cap 0: starting GC > > I don't believe any solution involving MVars will work for the non-threaded > RTS. Though I'd love to be wrong here... > > Regards, > Tamar ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Blocking a task indefinitely in the RTS
What if you wrap the MVar in a foreign closure? import Control.Concurrent.MVar (newEmptyMVar, putMVar, takeMVar) import Control.Exception (bracket) import Foreign.Ptr (FunPtr, freeHaskellFunPtr) foreign import ccall "wrapper" wrapAwaken :: IO () -> IO (FunPtr (IO ())) main = do mvar <- newEmptyMVar bracket (wrapAwaken (putMVar mvar ())) freeHaskellFunPtr $ \ awaken -> do -- giveToExternalCode awaken takeMVar mvar On Sun, Jan 6, 2019, at 10:37, Phyx wrote: > Hi All, > > I'm looking for a way to block a task indefinitely until it is woken up by > an external event in both the threaded and non-threaded RTS and returns a > value that was stored/passed. MVar works great for the threaded RTS, but > for the non-threaded there's a bunch of deadlock detection in the scheduler > that would forcibly free the lock and resume the task with an opaque > exception. This means that MVar and anything derived from it is not usable. > > STMs are more expensive but also have the same deadlock code. So again no > go. The reason it looks like a deadlock to the RTS is that the "Wake-up" > call in the non-threaded rts will come from C code running inside the RTS. > The RTS essentially just sees all tasks blocked on it's main capability and > (usually rightly so) assumes a deadlock occurred. > > You have other states like BlockedOnForeign etc but those are not usable as > a primitive. Previous iterations of I/O managers have each invented > primitives for this such as asyncRead#, but they are not general and can't > be re-used, and requires a different solution for threaded and non-threaded. > > I have started making a new primitive IOPort for this, based on the MVar > code, but this is not trivial... (currently I'm getting a segfault > *somewhere* in the primitive's cmm code). The reason is that the semantics > are decidedly different from what MVars guarantee. I should also mention > that this is meant to be internal to base (i.e no exported). > > So before I continue down this path and some painful debugging..., does > anyone know of a way to block a task, unblock it later and pass a value > back? It does not need to support anything complicated such as multiple > take/put requests etc. > > Cheers, > Tamar > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Removing core-spec.pdf from repository?
On Tue, Mar 14, 2017, at 10:20, Elliot Cameron wrote: > The only loss is the ability to look at changes over time. GHC docs are archived for every version number: https://downloads.haskell.org/~ghc//... So it would remain possible to compare the changes between each release. The only problem is the discontinuity caused by this migration. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Removing core-spec.pdf from repository?
> I also dislike generated files in repos, but would like to point out > that there are a few pages out there that reference the link > https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf > directly; these would brake. But there is probably nothing we can > easily do about that. Could replace it with a plain text file that says: "MOVED to https://XXX; The build system could then be tweaked to output the .pdf somewhere else so it would not overwrite this dummy file. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Attempt at a real world benchmark
> It could tell us which language features are most used. A lot could be gleaned just by analyzing the packages on Hackage though. For example: https://www.reddit.com/r/haskell/comments/31t2y9/distribution_of_ghc_extensions_on_hackage/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Request for feedback: deriving strategies syntax
I would prefer "custom" simply because the word is used often enough in computing that there is no chance of someone having to pull out a dictionary for it. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
> Another great question that has come up is about Haddock output (Hackage). I > think Haddock needs to add a facility where library authors can include > specializations of an overly general type. This can be done in commentary, > but it's not as prominent. I think a low-hanging fruit would be to add the ability for Haddock to parse some sort of specialized types annotation (could be entirely in the comments) and display them adjacent to the true type. The types do have to be manually written, but at least they can be type-checked. Lens does this in its documentation and they are very helpful for learning the library. > (^.) :: s -> Getting a s a -> a > (^.) :: s -> Getter s a -> a > (^.) :: Monoid m => s -> Fold s m -> m > (^.) :: s -> Iso' s a -> a > (^.) :: s -> Lens' s a -> a > (^.) :: Monoid m => s -> Traversal' s m -> m ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Foreign calls and periodic alarm signals
> a good start would be to open a ticket. Okay, done: https://ghc.haskell.org/trac/ghc/ticket/10840 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Foreign calls and periodic alarm signals
TL;DR: Does 'foreign import safe' silence the periodic alarm signals? I received a report on this rather strange bug in 'directory': https://github.com/haskell/directory/issues/35#issuecomment-136890912 I've concluded based on the dtruss log that it's caused by the timer signal that the GHC runtime emits. Somewhere inside the guts of 'realpath' on Mac OS X, there is a function that does the moral equivalent of: while (statfs64(…) && errno == EINTR); On a slow filesystem like SSHFS, this can cause a permanent hang from the barrage of signals. The reporter found that using 'foreign import safe' mitigates the issue. What I'm curious mainly is that: is something that the GHC runtime guarantees -- is using 'foreign import safe' assured to turn off the periodic signals for that thread? I tried reading this article [1], which seems to be the only documentation I could find about this, and it didn't really go into much depth about them. (I also couldn't find any info about how frequently they occur, on which threads they occur, or which specific signal it uses.) I'm also concerned whether there are other foreign functions out in the wild that could suffer the same bug, but remain hidden because they normally complete before the next alarm signal. [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Documentation for GHC.IO.Exception
On Hackage, there seems to be no documentation for GHC.IO.Exception in base, but the package can in fact be imported so it's not exactly an internal package. directory and likely many other packages do use the GHC-specific error types like InappropriateType in exceptions, so it would be useful if there were a documentation page for these things even if there isn't any text. As it is right now, the discoverability of these error types is very low as you need to know the magical URL to show the source code: https://hackage.haskell.org/package/base/docs/src/GHC.IO.Exception.html That's also partly a problem with Haddock; AFAIK there's no way to navigate to the Source Code packages of modules whose documentation is disabled, even though they are in fact present if you can figure out the URL. So would it be OK to open up this module or is there a reason for keeping them discreet? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Typechecker / OverloadedStrings question 7.8 vs. 7.10
Would someone feel able to open a Trac ticket summarising this thread (as well as pointing to it), and making a proposal? Done: https://ghc.haskell.org/trac/ghc/ticket/10733 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Typechecker / OverloadedStrings question 7.8 vs. 7.10
Like this? Either use a type annotation to specify what 't0' should be based on these potential instance(s): instance Foo Bar -- Defined in 'Foo.Bar' ... and possibly more from other modules that the compiler has not yet encountered or define the required instance 'Foo t0' Not sure how best to present this. To explain this properly it's going to take several lines :\ --- Some other more general suggestions: it'd be nice to have - a unique tag for each GHC error, like 'ambiguous-type-variable' to improve searchability of error messages from GHC. The tag would also remain constant while the message may change over time. - a wiki that documents all the GHC errors. Not merely beginner-level advice, but also explanations of what causes them in all its gory details (so discussions like this could be pasted into that, for example). There is a stub already on https://wiki.haskell.org/GHC/Error_messages but it looks largely abandoned :( ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Typechecker / OverloadedStrings question 7.8 vs. 7.10
I think the error message could be made clearer simply by emphasizing the fact that type ambiguity over the lack of instances. Ambiguous type variable 't0' arising from a use of elem :: a - t0 a - Bool caused by the lack of an instance 'Data.String.IsString (t0 Char)' Either add a type annotation to dictate what 't0' should be based on one of the potential instances: instance Foldable (Either a) -- Defined in ‘Data.Foldable’ instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i = Foldable (GHC.Arr.Array i) -- Defined in ‘Data.Foldable’ ...plus three others) or define the required instance 'Data.String.IsString (t0 Char)'. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Seeking an active maintainer for 'directory'
Is anybody interested in nominating themselves for this role? I would be interested in this. I'm generally quite meticulous :) and I'm familiar with the APIs of both POSIX and Win32, albeit more so with POSIX. -- Phil ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
