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. Thi
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
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,
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!)
--
JohnDouglas
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
>
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 rea
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 10
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 ai
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
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
--- 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 STDI
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 function
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 enough
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, s
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
15 matches
Mail list logo