Glynn Clements <[EMAIL PROTECTED]> writes:
> They're similar, but not identical. Traditionally, Unix non-blocking
> I/O (along with asynchronous I/O, select() and poll()) were designed
> for "slow" streams such as pipes, terminals, sockets etc. Regular
> files and block devices are assumed to retu
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 read from the device into the buffer cache, then Unix
> >non-block
Nonblocking (asynchronous IO) is only one solution. Another is to use
blocking IO and
multiple threads. Each thread represents an IO dependency, in other
words there is no
point in a thread doing IO continuing because it needs the data it is
waiting for. Unassociated
threads do not get blocked a
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 read from the device into the buffer cache, then Unix
>non-
On Tue, 2005-01-18 at 22:52 +, Glynn Clements wrote:
> Ben Rudiak-Gould wrote:
> Essentially, reading data from regular files is always deemed to occur
> "soon", so the usual mechanisms for dealing with "slow" I/O (i.e.
> pipes, FIFOs, character devices, sockets) don't work. This applies
> eq
Ben Rudiak-Gould wrote:
> >Actually, If I were writing new haskell libraries, I would use mmap
> >whenever I could for accessing files. not only does it make the file
> >pointer problem go away, but it can be drastically more efficient.
>
> I'm not sure this is a good idea, because GHC really
On Mon, 2005-01-17 at 13:44 -0800, Ben Rudiak-Gould wrote:
> John Meacham wrote:
>
> >Actually, If I were writing new haskell libraries, I would use mmap
> >whenever I could for accessing files. not only does it make the file
> >pointer problem go away, but it can be drastically more efficient.
can't GHC do this using the threaded RTS?
Keean.
John Meacham wrote:
>Actually, If I were writing new haskell libraries, I would use mmap
>whenever I could for accessing files. not only does it make the file
>pointer problem go away, but it can be drastically more efficient.
I'm not sure this is
John Meacham wrote:
>Actually, If I were writing new haskell libraries, I would use mmap
>whenever I could for accessing files. not only does it make the file
>pointer problem go away, but it can be drastically more efficient.
I'm not sure this is a good idea, because GHC really needs non-blocking
On Wed, Jan 12, 2005 at 12:21:25AM +, Aaron Denney wrote:
> On 2005-01-11, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > On 11 January 2005 14:15, Gracjan Polak wrote:
> >
> >> Simon Marlow wrote:
> >> > There's a big lock on File. If you want to do truly concurrent
> >> reading, > you can mak
Marcin 'Qrczak' Kowalczyk wrote:
>File positions are not evil. They allow to treat files and devices
>in a uniform way.
Indeed, file positions are exactly as evil as indices into shared memory
arrays, which is to say not evil at all. But suppose each shared memory
array came with a shared "curren
Aaron Denney <[EMAIL PROTECTED]> writes:
> Does open("/dev/fd/n") or ("/proc/self/fd/n") act as dup() or a fresh
> open() to underlying file?)
As a dup(), with a side effect of resetting the file pointer to the
beginning.
It would not help anyway: if it's a terminal or pipe, it *has* to act
as a
On 2005-01-11, Simon Marlow <[EMAIL PROTECTED]> wrote:
> On 11 January 2005 14:15, Gracjan Polak wrote:
>
>> Simon Marlow wrote:
>> > There's a big lock on File. If you want to do truly concurrent
>> reading, > you can make multiple FileInputStreams, each of which has
>> its own file > descript
On 11 January 2005 14:15, Gracjan Polak wrote:
> Simon Marlow wrote:
> > There's a big lock on File. If you want to do truly concurrent
> reading, > you can make multiple FileInputStreams, each of which has
> its own file > descriptor (the Unix implementation uses dup(2)).
> >
>
> Original a
Simon Marlow wrote:
> There's a big lock on File. If you want to do truly concurrent reading,
> you can make multiple FileInputStreams, each of which has its own file
> descriptor (the Unix implementation uses dup(2)).
>
Original and descriptor returned by dup or dup2 share file pointer.
--
Gracj
On 11 January 2005 11:39, Marcin 'Qrczak' Kowalczyk wrote:
> Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
>
>> http://www.haskell.org/~simonmar/io/System.IO.html
>
> "fileRead :: File -> FileOffset -> Integer -> Buffer -> IO ()"
>
> This is unimplementable safely if the descriptor is read c
16 matches
Mail list logo
