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-blocking I/O (i.e.
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 return the
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
equally to
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
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 a
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.
I'm
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 make multiple
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 current
Simon Marlow [EMAIL PROTECTED] writes:
For unix, there are couple different tacks one could take. The locale
system is standard, and does work, but is ugly and a pain to work
with. In particular, it's another (set of) global variables. And
what do you do with a character not expressible in
On Mon, 10 Jan 2005 17:12:44 -, Simon Marlow [EMAIL PROTECTED] wrote:
Not a problem. Have you looked at the streams proposal?
I've missed most of the discussion on this, so if someone could just
clarify the reasons for a few things I find peculiar:
* Prefixing function names with their
On 2005-01-10, Simon Marlow [EMAIL PROTECTED] wrote:
- Can you do String I/O in some encoding of Unicode? No Haskell
compiler has support for this yet, and there are design decisions
to be made. Some progress has been made on an experimental
prototype (see recent discussion on this
On 11 January 2005 06:52, Andre Pang wrote:
Is there a Wiki page or URL with the steram proposal?
There is now:
http://www.haskell.org/hawiki/HaskellStreamIO
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
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 concurrently
by different processes. The current position is shared.
--
__(
Ketil,
Ketil Malde wrote:
Dimitry Golubovsky [EMAIL PROTECTED] writes:
(Did you intend this for the list?)
Yes, and I re-posted similar message on the list.
I think perhaps the answer is all of the above. The functions could
be defined in multiple modules, so that 'ASCII.isSpace' would match
the
On 11 January 2005 09:00, Sebastian Sylvan wrote:
On Mon, 10 Jan 2005 17:12:44 -, Simon Marlow
[EMAIL PROTECTED] wrote:
Not a problem. Have you looked at the streams proposal?
I've missed most of the discussion on this, so if someone could just
clarify the reasons for a few
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 concurrently
by
Marcin 'Qrczak' Kowalczyk wrote:
fileRead :: File - FileOffset - Integer - Buffer - IO ()
This is unimplementable safely if the descriptor is read concurrently
by different processes. The current position is shared.
UNIX98 defines function:
extern ssize_t pread (int __fd, void *__buf,
Okay, I've taken a look (there seems to be some differences between
the web page and the tgz from the wiki - fileGet seems to have
disappeared). I still don't grok much of it, so just ignore me if I'm
being overly naive.
Anyway. Let's see, I can now open a stream from a file by doing:
f
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.
--
Gracjan
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 and
Marcin 'Qrczak' Kowalczyk wrote:
fileRead :: File - FileOffset - Integer - Buffer - IO ()
This is unimplementable safely if the descriptor is read concurrently
by different processes. The current position is shared.
... which is terrible library design, which we should avoid if at all
possible,
Ben Rudiak-Gould [EMAIL PROTECTED] writes:
fileRead can be implemented in terms of OS primitives,
Only if they already support reading from a fixed offset (like pread).
I'm not sure if we can rely on something like this being always
available, or whether it should be emulated using lseek which
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 descriptor (the Unix
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 dup()
On 08 January 2005 08:09, Aaron Denney wrote:
On 2005-01-07, Simon Marlow [EMAIL PROTECTED] wrote:
- Can you use (some encoding of) Unicode for your Haskell source
files? I don't think this is true in any Haskell compiler right
now.
I assume this won't be be done until the next one is
Simon Marlow wrote:
Not a problem. Have you looked at the streams proposal?
Is there a Wiki page or URL with the steram proposal?
--
% Andre Pang : trust.in.love.to.save http://www.algorithm.com.au/
___
Haskell-Cafe mailing list
Andre Pang wrote:
Is there a Wiki page or URL with the steram proposal?
It's here:
http://www.haskell.org/~simonmar/io/System.IO.html
-- Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 2005-01-07, Simon Marlow [EMAIL PROTECTED] wrote:
- Can you use (some encoding of) Unicode for your Haskell source files?
I don't think this is true in any Haskell compiler right now.
I assume this won't be be done until the next one is done...
- Can you do String I/O in some encoding
On Sat, Jan 08, 2005 at 08:08:38AM +, Aaron Denney wrote:
I suppose I wouldn't be too upset at using the locale information, but
defaulting to UTF-8, rather than ASCII for unset character set
information.
But if we default to a UTF-8 encoding, then there could be decoding
failures when
29 matches
Mail list logo
