Nicholas Clark <[EMAIL PROTECTED]> writes:
>
>tell can be seek F, 0, SEEK_CUR
I initally had stdio like split seek/tell. I actually implemented
the merged form as you suggest - but it turned out to be a mistake
so they are currently separate again.
The reason it is a mistake is one wants seek(F,0,SEEK_CUR) to be
right thing to do which switching read/write etc. Which means it has
to synchronize (flush) the buffers.
But you do not _need_ to flush the buffers to do tell() - and it is
thus much faster if code is tell()-ing "just in case" to avoid the flush.
(Which is not to say that flush/sync is not also a vtable entry for other
reasons.)
>
>(unless tell is intended to return some other information on unseekable
>files. In which case internally one could use a fourth value next to
>SEEK_SET, SEEK_CUR, SEEK_END internally for tell, if saving one vtable
>slot is worthwhile)
vtable slots are fairly cheap - the tables are per-module not per-handle.
One reason perl5's PerlIO has so many is that it proved useful doing
mmap() and crlf() layers to be able to "inherit" some entries from
generic "perlio" layer. So more-but-simpler entries avoided
messy tests.
>
>> push_filter
>> pop_filter
>> read
>> unread
>> write
>> prefetch
>>
>> and maybe have the return data have some 'I/O complete' marker so async I/O
>> will work out properly.
Anyone that has experience in writing prefetch style code please weigh in
with the pitfalls.
>
>Nicholas Clark
--
Nick Ing-Simmons
