[Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

Simon Marlow simonmar at microsoft.com
Wed Jan 19 10:33:41 EST 2005


We do use a thread pool.  But you still need as many OS threads as there
are blocked read() calls, unless you have a single thread doing select()
as I described.  BTW our Haskell Workshop paper from last year describes
this stuff:

  http://www.haskell.org/~simonmar/papers/conc-ffi.ps.gz

Cheers,
	Simon

On 19 January 2005 15:07, Keean Schupke wrote:

> Why not use a thread-pool, and a "safe" call to read, provided there
> is an OS thread available,
> defaulting to "unsafe" if no thread is available... You could make the
> thread pool size an argument...
> 
>     Keean.
> 
> Simon Marlow wrote:
> 
>> On 19 January 2005 13:50, William Lee Irwin III wrote:
>> 
>> 
>> 
>>> On 19 January 2005 09:45, Ben Rudiak-Gould wrote:
>>> 
>>> 
>>>>> Okay, my ignorance of Posix is showing again. Is it currently the
>>>>> case, then, that every GHC thread will stop running while a disk
>>>>> read is in progress in any thread? Is this true on all platforms?
>>>>> 
>>>>> 
>>> On Wed, Jan 19, 2005 at 01:39:05PM -0000, Simon Marlow wrote:
>>> 
>>> 
>>>> It's true on Unix-like systems, I believe.  Even with -threaded. 
>>>> It might not be true on Win32. 
>>>> 
>>>> 
>>> How does forkOS fit into this picture? It's described in the
>>> documentation as allowing concurrent execution of system calls
>>> and other activity by other threads.
>>> 
>>> 
>> 
>> forkOS doesn't fix this.  It forks another OS thread which can be
>> used to make concurrent foreign calls, if they are not marked
>> "unsafe". However, the standard I/O library, in -threaded mode, does
>> read like this: 
>> 
>>        - non-blocking, "unsafe", read() to see what's there
>>        - if read() would block, then hand off to another
>>          Haskell thread which does select() on all the outstanding  
>> IO requests. 
>> 
>> This scheme is just for efficiency.  We could (and used to) just call
>> "safe" read() for every read - that would give you the right
>> concurrency with -threaded, but unfortunately you'd really notice
>> the difference if you had 1000s of threads all doing IO, because
>> each one would need its own OS thread.  The current scheme is rather
>> snappy (even snappier than non-threaded, as it happens). 
>> 
>> You can always do System.Posix.fileRead to get around it.
>> 
>> Cheers,
>> 	Simon
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe



More information about the Haskell-Cafe mailing list