At 11:53 PM 9/26/00 -0400, Uri Guttman wrote:
>now what bothers me is that all those calls are in section 3 and are no
>section 2 system calls. maybe it is faked with threads but i haven't
>found any support for that notion. if so, i wonder if we can actually
>use it and not collide with perl threads?
Sure, that's not a problem.
I don't much care how its faked (if it is) as long as it works. Might not
be as efficient as full kernel support for async I/O, but it'll do. At
least there's some overlap. (You can get better device request ordering and
do I/O coalescing if you have more than one request handy)
It wouldn't entirely surprise me to find these were done with threads now,
but in a rev or two the kernel did it 'right'.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
- Re: RFC 310 (v1) Ordered bytecode Michael Maraist
- Re: RFC 310 (v1) Ordered bytecode Simon Cozens
- Re: RFC 310 (v1) Ordered bytecode Dan Sugalski
- Re: RFC 310 (v1) Ordered bytecode Dave Storrs
- Re: RFC 310 (v1) Ordered bytecode Dan Sugalski
- Re: RFC 310 (v1) Ordered bytecode Uri Guttman
- Re: RFC 310 (v1) Ordered bytecode Simon Cozens
- Re: RFC 310 (v1) Ordered bytecode Dan Sugalski
- Re: RFC 310 (v1) Ordered bytecode Tom Hughes
- Re: RFC 310 (v1) Ordered bytecode Uri Guttman
- Re: RFC 310 (v1) Ordered bytecode Dan Sugalski
- Re: RFC 310 (v1) Ordered bytecode Simon Cozens
- Re: RFC 310 (v1) Ordered bytecod... Uri Guttman
- Re: RFC 310 (v1) Ordered bytecod... Dan Sugalski
- Re: RFC 310 (v1) Ordered bytecode Tom Hughes
- Re: RFC 310 (v1) Ordered bytecod... Dan Sugalski
- Re: RFC 310 (v1) Ordered bytecode Tom Hughes
- async i/o (was Re: RFC 310 (v1) Orde... Uri Guttman
- Re: async i/o (was Re: RFC 310 (... Nicholas Clark
