Re: PerlIO - what next? - (should getc get a character?)

Uri Guttman <[email protected]> writes:
>>>>>> "NI" == Nick Ing-Simmons <[email protected]> writes:
>
><p5p removed>
>
>  NI> I have guts of a stack-of-layers PerlIO scheme coded now 
>  NI> (//depot/perlio/... for those with perforce access - merge to 5.7.0
>  NI> will occur as soon a Jarrko likes.)
>
>does it support multiple instances for threads 

Not yet.

>and async i/o? 

If I can find a system that has async IO I will give it a try.
I may do Win32 system that way ...

>what about
>event handling and such? 

What I have so far is "sfio like" except that the "vtable" that disciplines
define (which I call layers) is larger and it is coded in a more object-oriented
style (and of course is under perl's license).

There is nothing stopping an event system doing 

  splice(@perlio::layers,1,0,@layers_to_handle_blocking);

but the mechanism to mess with per-handle layer stack is not really there yet.
Right now we only have unix (read), stdio (fread) and perlio (buffer layer).
I/we need to code a few more "layers" to get a feel for 


>i think we need to make a proper api spec on
>how the i/o subsystem looks to the outside world and also how it
>interacts with the perl6 kernel. as the kernel hasn't been spec'ed or
>whatever, we have to wait on that some more.
>
>but i am glad to hear of code that we can use as a first draft.

I am not sure this code is a "draft" for perl6 - more of an experiment 
so we can see what does('nt) work. The OO ANSI-C with vtable stuff I 
used is also and experiment to see what it costs before we start wholesale
coding of perl6.

-- 
Nick Ing-Simmons