Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions
k.schupke at imperial.ac.uk
Wed Jan 19 10:06:38 EST 2005
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...
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
> - 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.
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
More information about the Haskell-Cafe