>>>>> "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 operations for opening and closing a filehandle, AR> and only using asynchronous operations for the heavy lifting of AR> slurping in an entire file. 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 optional timeout arg). in all cases you got a return value with either status (sync) or event handle (async). you could combine the returns into one object as mentioned in this thread. AR> But, yes, I agree with the principle of not maintaining two AR> completely separate implementations for synchronous and AR> asynchronous ops. The earlier design approached that by having the AR> synchronous ops be asynchronous internally, but my draft suggests AR> this be handled by having the asynchronous ops use the synchronous AR> ops internally. what you do is make the internal sync op be implemented by the internal async op. all that is needed is a wrapper around the async op with a callback that saves the results where the sync call can get them. the sync wrapper must somehow yield (block in a thread?) until the actual async op is done. then it can continue with the sync op and return to the caller. this is very easy with the ideas dan was doing a while back. the p6 level sync call is broken up into a couple (or more) parrot op codes. the first sets up the i/o op and it is always async. it the p6 call was async then it returns to p6 and the usual callbacks will work. if the p6 was sync then the next parrot op would be a wait on i/o thing. it would block the thread until the i/o was completed. this could be a wait for event or from the underlying async i/o system. yes it is a little handwaving but the idea is that you can have a single p6 i/o api which supports sync and async behavior and a single implementation which only really does async and it does sync with special i/o wait ops. and this goes way back to RT-11 on the pdp-11. it had three forms of i/o calls, READ (async), READC (read with completion routine - what they named callbacks) and READW (sync read). they also had a WAIT op that was handle specific. READW was probably implemented as a READ followed by a WAIT. so there is nothing new under the sun or under the hood of p6. just go with the tried and true way to handle sync and async i/o. thanx, uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
