Re: [GHC] #7216: Compositional blocking on file descriptors

2013-01-02 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  igloo   
  Type:  feature request   | Status:  patch   
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by AndreasVoellmy):

 I made a new patch that implements the threadWaitReadSTM and
 threadWaitWriteSTM functions for Windows with the threaded RTS.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:14
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2013-01-02 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  igloo   
  Type:  feature request   | Status:  patch   
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by AndreasVoellmy):

 Sorry for all the patches. You can ignore all, but the last. expose-
 threadWaitSTM-on-master.2.patch which expose-threadWaitSTM-on-
 master.3.patch fixed. expose-threadWaitSTM-on-master.4.patch is a minor
 simplification.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:15
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2013-01-01 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  igloo   
  Type:  feature request   | Status:  patch   
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by igloo):

 I'm a bit confused. Do these functions work on Windows? In
 Control.Concurrent they just raise an exception on Windows, but it looks
 like in GHC.Conc.IO they are defined on Windows.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:12
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2013-01-01 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  igloo   
  Type:  feature request   | Status:  patch   
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by AndreasVoellmy):

 I think the confusion also exists for the threadWaitRead and
 threadWaitWrite functions. They are defined in GHC.Conc.IO even for
 Windows, but then they seem to be completely ignored in Control.Concurrent
 and the functions of the same name there are defined for Windows only in
 the threaded RTS (or for stdin in non-threaded RTS).

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:13
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-12-31 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  
  Type:  feature request   | Status:  new 
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

  * status:  closed = new
  * resolution:  fixed =


-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-12-31 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  igloo   
  Type:  feature request   | Status:  new 
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

  * owner:  = igloo


-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:10
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-12-31 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  igloo   
  Type:  feature request   | Status:  patch   
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

  * status:  new = patch


-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-12-30 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  
  Type:  feature request   | Status:  closed  
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:  fixed |   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by AndreasVoellmy):

 The previous patches did not actually expose the new functions in any
 public module. The attached patch exports these functions in
 Control.Concurrent, which is where the threadWaitRead and threadWaitWrite
 functions are exported.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-12-02 Thread GHC
#7216: Compositional blocking on file descriptors
---+
  Reporter:  AndreasVoellmy|  Owner:  
  Type:  feature request   | Status:  closed  
  Priority:  normal|  Milestone:  7.8.1   
 Component:  libraries/base|Version:  7.4.2   
Resolution:  fixed |   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by igloo):

  * status:  patch = closed
  * resolution:  = fixed


Comment:

 Applied, thanks!

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-10-17 Thread GHC
#7216: Compositional blocking on file descriptors
-+--
Reporter:  AndreasVoellmy|   Owner:  
Type:  feature request   |  Status:  patch   
Priority:  normal|   Milestone:  7.8.1   
   Component:  libraries/base| Version:  7.4.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by AndreasVoellmy):

 The last patch addresses the previous comment by igloo.  I made the
 threadWaitSTM return an IO action that unregisters interest in the file
 descriptor.  By returning an `IO ()` value we avoid having to export the
 `FdKey` type and `unregsterFd` functions.

 I also added some haddock comments to `threadWaitReadSTM` and
 `threadWaitWriteSTM`.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-10-16 Thread GHC
#7216: Compositional blocking on file descriptors
-+--
Reporter:  AndreasVoellmy|   Owner:  
Type:  feature request   |  Status:  patch   
Priority:  normal|   Milestone:  7.8.1   
   Component:  libraries/base| Version:  7.4.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by igloo):

  * milestone:  = 7.8.1


Comment:

 This patch warns that the return values of `registerFd` and
 `unregisterFd_` are ignored. Is that correct?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-10-16 Thread GHC
#7216: Compositional blocking on file descriptors
-+--
Reporter:  AndreasVoellmy|   Owner:  
Type:  feature request   |  Status:  patch   
Priority:  normal|   Milestone:  7.8.1   
   Component:  libraries/base| Version:  7.4.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by AndreasVoellmy):

 `threadWaitSTM` basically follows the template `threadWait`. `threadWait`
 also ignores the result of applications of unregisterFd_, so on this point
 it is no different than the code that is already in that module.

 Regarding the result of `registerFd`: `threadWait` uses the result of
 `registerFd` in only one place: it creates an empty `MVar`, registers a
 callback that fills it and waits on the `MVar` handling any exceptions
 thrown to the thread (it unregisters the callback on exception);
 unregistering is the only place the result of `registerFd` is used.

 `threadWaitSTM` does not block on an `MVar` (or anything else, that is
 the point of it), so it cannot use the result of `registerFd` in the
 same way.  To accomplish the same thing on an exception (i.e.
 unregistering the callback) we should probably return the registration key
 in the result of `threadWaitSTM` so that the user can handle and
 unregister.  This would require also re-exporting the unregistration
 function in `GHC.Event.Thread`, since it is currently exported from the
 non-exposed `GHC.Event.Manager` module.

 On the other hand, I don't really see why unregistering is
 necessary for correctness. It seems to me like unregistering is an
 optimization, since
 it keeps the callback table smaller. If this occurs and the registered
 file is ever ready, then the
 callback will fire and be unregistered.  If the registered file is
 never ready, then the file will never be removed from the callback
 table, but this could happen with a file anyway even when no error occurs.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-10-15 Thread GHC
#7216: Compositional blocking on file descriptors
-+--
Reporter:  AndreasVoellmy|   Owner:  
Type:  feature request   |  Status:  patch   
Priority:  normal|   Milestone:  
   Component:  libraries/base| Version:  7.4.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 Looks good to me.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


[GHC] #7216: Compositional blocking on file descriptors

2012-09-03 Thread GHC
#7216: Compositional blocking on file descriptors
--+-
 Reporter:  AndreasVoellmy|  Owner:  
 Type:  feature request   | Status:  new 
 Priority:  normal|  Component:  libraries/base  
  Version:  7.4.2 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 The GHC.Event.Thread module provides threadWaitRead, threadWaitWrite :: Fd
 - IO () calls that block until a particular file descriptor is ready for
 reading or writing. With this API a single thread cannot wait on multiple
 file descriptors or a file descriptor and some other condition (e.g. an
 MVar, STM transaction, etc). One could work around this by creating extra
 producer threads that each monitor one file descriptor and then multiplex
 messages from those threads onto a single channel (or mvar, etc) and then
 have a consumer thread that waits on this single multiplexed channel.
 Unfortunately, this extra indirection imposes a modest performance penalty
 in the form of longer wait times to service events due to having to switch
 between multiple threads to handle a single ready file.

 I propose to provide analogous functions in the STM monad
 threadWaitReadSTM,threadWaitWriteSTM :: Fd - STM (). These will allow a
 single thread to wait on multiple files or both files and other
 conditions. This eliminates the switching between threads to service a
 request.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #7216: Compositional blocking on file descriptors

2012-09-03 Thread GHC
#7216: Compositional blocking on file descriptors
--+-
 Reporter:  AndreasVoellmy|  Owner:  
 Type:  feature request   | Status:  patch   
 Priority:  normal|  Component:  libraries/base  
  Version:  7.4.2 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
Changes (by AndreasVoellmy):

  * status:  new = patch


-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs