Ketil Malde wrote:
The point is that the Unix documentation does not consider the short
pause as data is read off your hard drive to be blocking. So that's why
select will always report that data is available when you use it with a
file handle.
Isn't this also for historic reasons?
Ben Rudiak-Gould [EMAIL PROTECTED] schrieb am 21.01.05 02:37:34:
If you're reading from a random-access file, there's no way [select] can tell
you when the file data is buffered, because it doesn't know which part
of the file you plan to read. The OS may try to guess for readahead
Glynn Clements wrote:
The central issue is that the Unix API doesn't distinguish between
cases 1 and 2 when it comes to non-blocking I/O, asynchronous I/O,
select/poll etc. [OTOH, NT overlapped I/O and certain Unix extensions
do distinguish these cases, i.e. data is only available when it's in
Ben Rudiak-Gould wrote:
If you're reading from a random-access file, there's no way it can
tell you when the file data is buffered, because it doesn't know which
part of the file you plan to read. The OS may try to guess for
readahead purposes, but select()'s behavior can't depend on that
On Fri, 2005-01-21 at 12:33 +, Keean Schupke wrote:
Glynn Clements wrote:
The central issue is that the Unix API doesn't distinguish between
cases 1 and 2 when it comes to non-blocking I/O, asynchronous I/O,
select/poll etc. [OTOH, NT overlapped I/O and certain Unix extensions
do
On Fri, Jan 21, 2005 at 12:42:56PM +, Keean Schupke wrote:
Ben Rudiak-Gould wrote:
If you're reading from a random-access file, there's no way it can
tell you when the file data is buffered, because it doesn't know which
part of the file you plan to read. The OS may try to guess for
Duncan Coutts [EMAIL PROTECTED] writes:
The point is that the Unix documentation does not consider the short
pause as data is read off your hard drive to be blocking. So that's why
select will always report that data is available when you use it with a
file handle.
Isn't this also for
Udo Stenzel wrote:
The Glibc documentation says, select determines if there is data available
(more precisely, if a call to read(2) will not block). I think, this is reasonably
precise. The OS does know, where you are going to read (at the file pointer)
and if you seek() or pread() instead,
On Fri, 2005-01-21 at 16:26 +, Keean Schupke wrote:
Udo Stenzel wrote:
Thus the question is, does select() reliably tell if read() would block or
does it
check for something else? Is the documentation wrong (on some platforms)?
Having read around I have found that select does
On 19 January 2005 20:31, Glynn Clements wrote:
Keean Schupke 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?
It's true on Unix-like
On 19 January 2005 20:33, Glynn Clements wrote:
Simon Marlow wrote:
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.
How does the select() help? AFAIK, select() on a regular
Why is disk a special case? I have never heard that all processes under
linux
wait for a disk read... The kernel most certainly does not busy wait for
disks
to respond, so the only alternative is that the process that needs to wait
(and only that process) is put to sleep. In which case a second
On 19 January 2005 16:58, Keean Schupke wrote:
Simon Marlow wrote:
This is what GHC does, if I understand you correctly. The thread
running select() does so in its own OS thread, while another OS
thread runs the Haskell code. As long as you use -threaded, that
is. Oh, and before GHC 6.4
Simon Marlow wrote:
We're getting a bit confused here. Keean: the original question was
about whether a disk read will stop all other *Haskell* threads. Not OS
threads. The two are quite different beasts in GHC.
Cheers,
Simon
But if GHC is running with the -threaded flag, then other
On 20 January 2005 09:56, Keean Schupke wrote:
Why is disk a special case? I have never heard that all processes
under linux wait for a disk read...
You were talking about Haskell threads, not processes! These are quite
different things.
The kernel most certainly does not busy wait for
Simon Marlow wrote:
On 20 January 2005 09:56, Keean Schupke wrote:
Why is disk a special case? I have never heard that all processes
under linux wait for a disk read...
You were talking about Haskell threads, not processes! These are quite
different things.
But with -threaded GHC is
On 20 January 2005 10:01, Keean Schupke wrote:
Simon Marlow wrote:
We're getting a bit confused here. Keean: the original question was
about whether a disk read will stop all other *Haskell* threads.
Not OS threads. The two are quite different beasts in GHC.
Cheers,
Simon
Simon Marlow wrote:
Yes, except that you forgot that not all foreign calls can run
concurrently with Haskell code. Only the safe ones can.
Okay, now I understand what is going on. Why is there extra overhead
for a 'safe' call?
Keean.
//
___
But does it matter... If the select says the read will block you schedule
another haskell thread, if select says the read will not block, you do the
read. I don't see the problem... (Okay, I can see that if select lies,
and the
read takes a long time you might miss the next scheduling timeslot -
On 20 January 2005 11:30, Keean Schupke wrote:
Simon Marlow wrote:
Yes, except that you forgot that not all foreign calls can run
concurrently with Haskell code. Only the safe ones can.
Okay, now I understand what is going on. Why is there extra overhead
for a 'safe' call?
A safe
read. I don't see the problem... (Okay, I can see that if select lies,
and the
read takes a long time you might miss the next scheduling timeslot - but
as far as I am aware select doesn't lie, and read will return immediately
if select says there is data ready)...
select() _does_ lie for
Keith Wansbrough wrote:
read. I don't see the problem... (Okay, I can see that if select lies,
and the
read takes a long time you might miss the next scheduling timeslot - but
as far as I am aware select doesn't lie, and read will return immediately
if select says there is data ready)...
Keean Schupke wrote:
Why is disk a special case?
With slow streams, where there may be an indefinite delay before the
data is available, you can use non-blocking I/O, asynchronous I/O,
select(), poll() etc to determine if the data is available.
If it is, reading the data is essentially just
Keean Schupke wrote:
read. I don't see the problem... (Okay, I can see that if select lies,
and the
read takes a long time you might miss the next scheduling timeslot - but
as far as I am aware select doesn't lie, and read will return immediately
if select says there is data
Glynn Clements wrote:
Keean Schupke wrote:
Why is disk a special case?
With slow streams, where there may be an indefinite delay before the
data is available, you can use non-blocking I/O, asynchronous I/O,
select(), poll() etc to determine if the data is available.
[...]
With files or block
On 19 January 2005 09:45, Ben Rudiak-Gould wrote:
Glynn Clements wrote:
Ben Rudiak-Gould wrote:
GHC really needs non-blocking
I/O to support its thread model, and memory-mapped I/O always
blocks.
If, by blocks, you mean that execution will be suspended until the
data has been
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 -, Simon
Simon Marlow 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?
It's true on Unix-like systems, I believe. Even with -threaded. It
might
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
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
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,
On Wed, 2005-01-19 at 15:06 +, 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...
If it's just a question of speed then
Duncan Coutts wrote:
If it's just a question of speed then the fastest IO system is the
variety that GHC uses now: a single OS thread that multiplexes all IO
requests using a select loop.
But what about the continuing computation... we do not want
the fastest IO system, but we want the program
Simon Marlow wrote:
On 19 January 2005 16:49, Keean Schupke wrote:
But what about the continuing computation... we do not want
the fastest IO system, but we want the program to comlete the
fastest... So ideally we want 2 threads!
One runs the Haskell code that is not waiting for IO. (IE other
Keean Schupke 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?
It's true on Unix-like systems, I believe. Even with -threaded. It
Simon Marlow wrote:
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.
How does the select() help? AFAIK, select() on a regular file or block
device will always indicate that it is
Glynn Clements [EMAIL PROTECTED] writes:
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.
How does the select() help? AFAIK, select() on a regular file or block
device will
37 matches
Mail list logo
