On Mar 19, 2006, at 0:23, Uri Guttman wrote:
if you look at the rfc's (remember those? :) i wrote on this topic,
you
will see that i proposed just that form of api (not at OO as
these). the
only difference between a sync and async i/o op was the addition of a
callback argument (and an optio
On Mar 19, 2006, at 11:05, Nicholas Clark wrote:
Is the choice of implementation actually visible to a user of the API?
If "yes", where, and can we avoid it?
No.
At which point we have flexibility in
how things are actually implemented.
Yes.
I can see that emulating asynchronous ops with
On Sat, Mar 18, 2006 at 11:01:34PM -0800, Allison Randal wrote:
: But, yes, I agree with the principle of not maintaining two
: completely separate implementations for synchronous and asynchronous
: ops. The earlier design approached that by having the synchronous ops
: be asynchronous intern
On Sat, Mar 18, 2006 at 11:01:34PM -0800, Allison Randal wrote:
> But, yes, I agree with the principle of not maintaining two
> completely separate implementations for synchronous and asynchronous
> ops. The earlier design approached that by having the synchronous ops
> be asynchronous inter
> "AR" == Allison Randal <[EMAIL PROTECTED]> writes:
AR> That interface is unnecessarily complex. But more importantly, the
AR> choice between async and sync is not set per filehandle, it's per
AR> operation. It could be very common to combine the two, such as
AR> using synchronous ope
On Mar 18, 2006, at 4:18, Leopold Toetsch wrote:
On Mar 18, 2006, at 5:05, Allison Randal wrote:
+=head3 Hybrid solution
+
+Another option is to return a status object from each I/O
operation.
I'm in favour of such a solution.
Also my favorite.
+The disadvantage is that a status o
On Mar 18, 2006, at 5:05, Allison Randal wrote:
Comments and questions welcome as usual.
+=head3 Hybrid solution
+
+Another option is to return a status object from each I/O operation.
I'm in favour of such a solution. There are several reasons:
- int status codes can't provide all th
I just committed a more complete draft of the I/O PDD to docs/pdds/
clip/pddXX_io.pod. I've integrated or responded to the mailing list
comments. I also added a good bit of additional discussion of
asynchronous operations and error handling. The original draft was
"how it works now", while t
