ParrotIO File-Descriptors

[Juergen Boemmels]

Hello,

at the moment I try to port IO-subsystem from the current
mem_sys_alloc/free to a PMC. The first patch in this direction is
nearly finished.

I have some problems with the File-Descriptors in Parrot. Some of the
operations in io.ops just take an INT File-Descriptor, which takes its
infromation from a table in the Interpreter-Structure. This hinders
garbage-collection of the IOs in this descriptor-table, because every
interger can possibly be a File-Descriptor. Furthermore this table
needs to be initialised early in the startup of parrot, at the moment
even the memory-subsystem is not running when the IO is initialised.

Therefor I propose:
Remove the integer-valued File-Descriptors. The ParrotIO-objects
(wrapped in PMCs) are the only way to access IO. The
standard-descriptors stdin/stdout/stderr can be obtained by new ops
get_stdin (out PMC)
get_stdout (out PMC)
get_stderr (out PMC)
respectivly the macros
PIO_STDIN(interpreter);
PIO_STDOUT(interpreter);
PIO_STDERR(interpreter);

If communication with external file-descriptors is necessary then the
PIO_fdopen function should be used, and the result is again a
ParrotIO-object.

bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47

[Clinton Pierce]

> Therefor I propose:
> Remove the integer-valued File-Descriptors. The ParrotIO-objects
> (wrapped in PMCs) are the only way to access IO. The
> standard-descriptors stdin/stdout/stderr can be obtained by new ops
> get_stdin (out PMC)
> get_stdout (out PMC)
> get_stderr (out PMC)
> respectivly the macros
> PIO_STDIN(interpreter);
> PIO_STDOUT(interpreter);
> PIO_STDERR(interpreter);
>
> If communication with external file-descriptors is necessary then the
> PIO_fdopen function should be used, and the result is again a
> ParrotIO-object.

Nice thoughts and probably the right direction. I'm a little vague on it's external interface though. What would the PMC interface look like from the PIR level?

new Px, ParrotIO
[... open the handle or whatever ...]
set Ix, Px # Get the FD number?

What about the other way around for those interfaces which require the programmer to give up the file descriptor directly, like ioctl() or fcntl()?

[Dan Sugalski]

At 3:05 PM +0200 6/26/03, Juergen Boemmels wrote:
>I have some problems with the File-Descriptors in Parrot. Some of the
>operations in io.ops just take an INT File-Descriptor, which takes its
>infromation from a table in the Interpreter-Structure. This hinders
>garbage-collection of the IOs in this descriptor-table, because every
>interger can possibly be a File-Descriptor. Furthermore this table
>needs to be initialised early in the startup of parrot, at the moment
>even the memory-subsystem is not running when the IO is initialised.

Since the I/O system is currently a combination of Melvin's IO stuff
implemented on top of a dodgy specification and all the hackish ops I
threw in so we could at least do *some* IO while I was futzing around
with the Async IO and events spec, feel free to get the machete out
and hack away at what's in there. We need to build a spec for the
stuff at some point, and now is as good a point as anay.

There's some preliminary design of the ops for I/O in PDD06, but
that's a bit out of date. Whatever we do, however, needs to take into
account the fact that we have the potential for IO filters (and lots
of them) in the style of PerlIO filters or SysV stream processing
modules (minus the SysV quirks), as well as asynchronous I/O, I/O
callback routines, and events to wedge in there.

For right now, the stuff you propose:

>Therefor I propose:
>Remove the integer-valued File-Descriptors. The ParrotIO-objects
>(wrapped in PMCs) are the only way to access IO. The
>standard-descriptors stdin/stdout/stderr can be obtained by new ops
>get_stdin (out PMC)
>get_stdout (out PMC)
>get_stderr (out PMC)
>respectivly the macros
>PIO_STDIN(interpreter);
>PIO_STDOUT(interpreter);
>PIO_STDERR(interpreter);

works just fine for me, and makes it easier for embedders to override
the filehandles (as they can poke stuff into the right spot on
startup). Tossing most of the I/O ops and leaving us with a base core
of:

open
close
readw
writew
readline
print

works for me. (Note the w's on the end of some of the op names, since
these'll be the blocking versions) We can add in more later, without
having to change the semantics of these.

Print and readline probably ought to go away, but they are just so
handy when writing code by hand I'd like to keep them for now, though
I'm OK with print being an alias for writew.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk