At 11:00 PM +0200 6/4/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Why don't we wait a bit? I should be done with the second draft of
the events/IO spec today, and we can go from there.
return ETOOMANYOPENENDSANDPENDINGSPECS; /* :) */
Way, *way* too many... :)
Sorry, work'
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Why don't we wait a bit? I should be done with the second draft of
> the events/IO spec today, and we can go from there.
return ETOOMANYOPENENDSANDPENDINGSPECS; /* :) */
leo
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 4:21 PM -0400 5/28/04, Uri Guttman wrote:
>> i am not against having a sync api but as dan said it should be a
>> wrapper around the async stuff. but as we agree (and dan hasn't acked
>> yet) the aio ops need a seek arg and the
At 4:21 PM -0400 5/28/04, Uri Guttman wrote:
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Uri Guttman <[EMAIL PROTECTED]> wrote:
>> this is another reason to drop seek/tell as separate ops and just add a
>> seek offset as an arg to the i/o ops. tell is useless in the aio
>
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Uri Guttman <[EMAIL PROTECTED]> wrote:
>> this is another reason to drop seek/tell as separate ops and just add a
>> seek offset as an arg to the i/o ops. tell is useless in the aio
>> world. the user code needs to manage its ow
Uri Guttman <[EMAIL PROTECTED]> wrote:
> this is another reason to drop seek/tell as separate ops and just add a
> seek offset as an arg to the i/o ops. tell is useless in the aio
> world. the user code needs to manage its own seek location and pass it
> into each call.
Well, yes that's true. OTO
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Why don't we wait a bit? I should be done with the second draft of
> the events/IO spec today, and we can go from there.
That's alway an option ;) But, if you did read on, there was a bit more
to think about. Not directly event/IO related.
And: fixing th
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> [3] the AIO docs in "info libc" indicate that after issueing an
LT> aio_read or aio_write, the file position is undefined, because these
LT> functions might execute in any order. The async tell or seek seems
LT> really to be nee
At 1:15 PM +0200 5/28/04, Leopold Toetsch wrote:
1) Async vs sync
Currently the ParrotIOLayerAPI [1] has distinct entries for Open,
Read, Write with _Async appended. These are of course all
unimplemented. Dan's draft [2] has additionally async variants of
seek and tell [3].
I'm thinking of a se
1) Async vs sync
Currently the ParrotIOLayerAPI [1] has distinct entries for Open, Read,
Write with _Async appended. These are of course all unimplemented. Dan's
draft [2] has additionally async variants of seek and tell [3].
I'm thinking of a separate IO layer (above the default OS layer(s)) th
10 matches
Mail list logo
