On Tue, Jul 16, 2002 at 08:12:22PM -0400, Melvin Smith wrote:
At 09:42 AM 7/16/2002 -0700, Damien Neil wrote:
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
True async IO implementations allow other things besides just notifying
the process when data is available. Things like
On Tuesday, July 16, 2002, 5:42:28 PM, you (mailto:[EMAIL PROTECTED]) wrote:
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
And the aioread/aiowrite/listio, etc. are a POSIX standard now, so they
should be reasonably available on most UNIXen.
Are the aio* calls available on
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
True async IO implementations allow other things besides just notifying
the process when data is available. Things like predictive seeks, or
bundling up multiple read/writes, etc. aren't doable with select/poll loops.
And the
Damien Neil wrote:
I'm not familiar with predictive seeks,
can you give a quick explanation?
It's very much like predictive loading of the instruction cache
in a cpu. It makes a heuristic guess that since you just read
1000 bytes in order, you're probably going to want to read the
next 1000
On Tue, Jul 16, 2002 at 11:35:10AM -0700, John Porter wrote:
Damien Neil wrote:
I'm not familiar with predictive seeks,
can you give a quick explanation?
It's very much like predictive loading of the instruction cache
in a cpu. It makes a heuristic guess that since you just read
1000
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
2) Filters (or IO disciplines) - People have different opinions on what
these
even mean. To me it means a layer that can be pushed onto an IO stack
that may filter or transform the data and/or perform opaque actions, while
Nicholas Clark wrote:
... PerlIO::subfile (treats a section
of a file as if it is a whole file - lets you read direct from a tar
on an uncompressed file stored in a zip file)
Ah -- just like Virtual File Systems (VFS) from Tcl-land.
Good idea!
('COURSE it's a good idea!)
--
At 09:42 AM 7/16/2002 -0700, Damien Neil wrote:
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
True async IO implementations allow other things besides just notifying
the process when data is available. Things like predictive seeks, or
bundling up multiple read/writes, etc.
--- Josh Wilmes [EMAIL PROTECTED] wrote:
IMHO, all IO in parrot should go through PIO, so
file descriptors should
not be used at all.
From io.ops:
This will go away when print ops are all migrated to
use ParrotIO instead of STDIO. Right now ParrotIO is
not stable enough to replace STDIO.
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
1) Async support. The IO system needs to be asynchronous and re-entrant
at the core, whether by threads or by use of the platform's async support.
Other things like callbacks assume other features of Parrot to be finished,
like
At 11:18 AM 7/15/2002 -0700, Damien Neil wrote:
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
1) Async support. The IO system needs to be asynchronous and re-entrant
at the core, whether by threads or by use of the platform's async support.
Other things like callbacks assume
For file I/O (in core.ops, not io.ops), do we want to use file descriptors or streams?
open uses fopen(), close uses fclose(), but read uses read(), and write uses write().
And all the comments
say descriptors.
Any opinions one which way the code should be patched?
--
Bryan Logan
I changed io.ops and pretty much the rest of parrot to always go through
PIO, which has streams. (or at least handles).
I left core.ops alone because I didn't know what the intent was. Are those
ops meant to be superseded by the ones in io.ops?
IMHO, all IO in parrot should go through PIO, so
IMHO, there's no way to find out quite like trying to use it :)
In my experiences with it thus far, it all seems to work fine. Melvin has
indicated that its API and internal structure may need some changes at
some point, but the basic functionality does seem to be there today, at
least
At 09:55 PM 7/14/2002 -0400, Josh Wilmes wrote:
IMHO, there's no way to find out quite like trying to use it :)
In my experiences with it thus far, it all seems to work fine. Melvin has
indicated that its API and internal structure may need some changes at
some point, but the basic
15 matches
Mail list logo
