Marcin 'Qrczak' Kowalczyk wrote:
Simon Marlow <[EMAIL PROTECTED]> writes:
I think the reason we set O_NONBLOCK is so that we don't have to test
with select() before reading, we can just call read(). If you don't
use O_NONBLOCK, you need two system calls to read/write instead of
one. This prob
On Fri, 24 Feb 2006, Marcin 'Qrczak' Kowalczyk wrote:
> Simon Marlow <[EMAIL PROTECTED]> writes:
>> I think the reason we set O_NONBLOCK is so that we don't have to test
>> with select() before reading, we can just call read(). If you don't
>> use O_NONBLOCK, you need two system calls to read/writ
Simon Marlow <[EMAIL PROTECTED]> writes:
> I agree that a generic select/poll interface would be nice.
We must be aware that epoll (and I think kqueue too) registers event
sources in advance, separately from waiting, which is its primary
advantage over poll.
The interface should use this model b
Simon Marlow <[EMAIL PROTECTED]> writes:
> I think the reason we set O_NONBLOCK is so that we don't have to test
> with select() before reading, we can just call read(). If you don't
> use O_NONBLOCK, you need two system calls to read/write instead of
> one. This probably isn't a big deal, given
Hello John,
Wednesday, February 22, 2006, 5:11:04 PM, you wrote:
it seems that we don't understand each other. let's be concrete:
my library reads and writes files. it uses read/write/recv/send to do
this in blocking manner. now i want to have another operations what will
have the SAME INTERFACE
On Wed, Feb 22, 2006 at 03:28:26PM +0300, [EMAIL PROTECTED] wrote:
> JM> Yeah, this is why I have held off on a specific design until we get a
> JM> better idea of what the new IO library will look like. I am thinking it
> JM> will have to involve some abstract event source type with primitive
> JM
Hello Donn,
Wednesday, February 22, 2006, 4:23:28 AM, you wrote:
DC> Could an application reasonably choose between several dispatching
DC> systems? For example, I'm working on a Macintosh here, where instead
DC> of X11 Apple provides its NextStep based GUI with its own apparently
DC> fairly wel
Hello John,
Wednesday, February 22, 2006, 3:32:34 AM, you wrote:
>> I agree that a generic select/poll interface would be nice. If it was
>> in terms of Handles though, that's not useful for implementing the I/O
>> library. If it was in terms of FDs, that's not portable - we'd need a
>> separ
On Tue, 21 Feb 2006, John Meacham wrote:
> Yeah, this is why I have held off on a specific design until we get a
> better idea of what the new IO library will look like. I am thinking it
> will have to involve some abstract event source type with primitive
> routines for creating this type from thi
On Tue, Feb 21, 2006 at 01:15:48PM +, Simon Marlow wrote:
> I agree that a generic select/poll interface would be nice. If it was
> in terms of Handles though, that's not useful for implementing the I/O
> library. If it was in terms of FDs, that's not portable - we'd need a
> separate one
Bulat Ziganshin wrote:
SM> I don't think async I/O is a stream transformer, fitting it into the
SM> stream hierarchy seems artificial to me.
yes, it is possible - what i'm trying to implement everything as
tranformer, independent of real necessity. i really thinks that
idea of transformers fit
John Meacham wrote:
On Fri, Feb 10, 2006 at 12:26:30PM +, Simon Marlow wrote:
in fact, I think this should be the basic API, since you can implement
readFD in terms of it. (readNonBlockingFD always reads at least one
byte, blocking until some data is available). This is used to partially
On Fri, Feb 10, 2006 at 12:26:30PM +, Simon Marlow wrote:
> in fact, I think this should be the basic API, since you can implement
> readFD in terms of it. (readNonBlockingFD always reads at least one
> byte, blocking until some data is available). This is used to partially
> fill an input bu
Bulat Ziganshin wrote:
Hello Einar,
Friday, February 10, 2006, 2:09:08 AM, you wrote:
as i understand this idea, transformer implementing async i/o should
intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate
type FD = Int
vGetBuf_async :: FD -> Ptr a -> Int -> IO Int
vPutBuf_as
14 matches
Mail list logo
