#7923: Optimization for takeMVar/putMVar when MVar left empty
------------------------------------+---------------------------------------
Reporter: ezyang | Owner: ezyang
Type: task | Status: new
Priority: normal | Component: Runtime System
Version: 7.7 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Blockedby:
Blocking: | Related:
------------------------------------+---------------------------------------
Right now, we always add an MVar to the mutable list when we
takeMVar/putMVar. However, this is unnecessary when the MVar is left
empty. This patch arranges that we don't add the MVar to the mutable list
in those cases. I've validated the patch but haven't checked performance
changes yet.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7923>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#6135: Unboxed Booleans
-------------------------------+--------------------------------------------
Reporter: benl | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler | Version: 7.4.1
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related: #605
-------------------------------+--------------------------------------------
Changes (by igloo):
* owner: jstolarek =>
* status: patch => new
Comment:
I have the impression that these patches need some more polishing before
they're ready to apply, so I'm reopening the ticket. Please let me know if
that's wrong.
Regarding the name of `sameMutableArray#`, I don't have a strong opinion.
I suspect there are few users of the function, so personally I'd be
inclined to use the most consistent names.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:74>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7985: Allow openFile on unknown file type
-----------------------------+----------------------------------------------
Reporter: singpolyma | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.6.3 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking: | Related:
-----------------------------+----------------------------------------------
There should be an "unknown" file type, to allow for special file types to
be opened without an exception.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7985>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4001: Implement an atomic readMVar
-------------------------------------------+--------------------------------
Reporter: simonmar | Owner: ezyang
Type: task | Status: new
Priority: low | Milestone: 7.6.2
Component: Runtime System | Version: 6.12.2
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Moderate (less than a day) | Testcase:
Blockedby: | Blocking:
Related: |
-------------------------------------------+--------------------------------
Comment(by ezyang):
I thought of a way to remove the extra queue: push reader threads onto the
front of the ordinary queue, then modify putMVar to loop through the queue
until it finds a taker. (The invariant is that reader threads are always
in the front.) Unfortunately, this seems incompatible with arranging for
the closure to be unlocked before the loop, since we won't know what the
new head pointer for the MVar should be until we've finished traversing
the queue.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4001#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4001: Implement an atomic readMVar
-------------------------------------------+--------------------------------
Reporter: simonmar | Owner: ezyang
Type: task | Status: new
Priority: low | Milestone: 7.6.2
Component: Runtime System | Version: 6.12.2
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Moderate (less than a day) | Testcase:
Blockedby: | Blocking:
Related: |
-------------------------------------------+--------------------------------
Comment(by ezyang):
It occurs to me that there is a problem with the current implementation,
which is that we may do an unbounded amount of work while the spinlock for
an MVar is taken out. Probably the right thing to do is arrange for the
closure to be unlocked before we start spinning up threads.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4001#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
