> DS> I'm also seriously considering throwing *all* PerlIO code into
> separate
> DS> threads (one per file) as an aid to asynchrony.
>
> but that will be hard to support on systems without threads. i still
> have that internals async i/o idea floating in my numb skull. it is an
> api that would look async on all platforms and will use the kernel async
> file i/o if possible. it could be made thread specific easily as my idea
> was that the event system was also thread specific.
>
I think we should have some thread abstraction layer instead of throwing
PerlIO into threads. The thread
abstraction layer can use either native thread package (blocking io), or
implement user level thread package
with either non-blocking io or async io. The internal io should be sync
instead of async. async is normally
slower than sync (most of unix don't have real async io), and thread is
cheap.
Hong
