At 12:33 PM 9/20/2001 -0700, Hong Zhang wrote:
> > 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.
I did say I was seriously considering it, not that I was going to do it. We
may well just throw the PerlIO stuff (at least anything with a filter) into
separate interpreters rather than separate threads. We'll see.
>The internal io should be sync instead of async.
Nope. Internal I/O, at least as the interpreter will see it is async. You
can build sync from async, it's a big pain to build async from sync.
Doesn't mean we actually get asynchrony, just that we can.
>async is normally slower than sync (most of unix don't have real async
>io), and thread is cheap.
Just because some systems have a really pathetic I/O system doesn't mean we
should penalize those that don't...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
