[RfC] Clean up of the ParrotIOLayerAPI
Juergen Boemmels
in the ParrotIOLayerAPI are some entries that might get cleaned up.
I want some feedback on my proposed removes and cleanups.
Open2_Unused
Open3_Unused
As the name already indicates. They are unused. I think they don't
belong here. The purpose of IPC::Open[23] is to create a process
which _uses_ some newly created IO-Objects. From the the view of the
IO-system these are 2 or 3 FDOpens during the Process execution
-> delete them from ParrotIOLayerAPI
OpenAsync
WriteAsync
ReadAsync
How should these work?
Write
PutS
Why are there two diffrent calls to write data to an io, with only a
slightly different prototype. This is code-duplication in every
layer. I can't think of any use case where PutS won't be implemented
as Write(..., data, strlen(data)). These two calls could be unified.
As a side note: The primary memory structure is the buffer, maybe
the unified call should take a buffer argument.
-> unify these two
Read
GetS
In this case there are two diffrent use-cases: Fill a preallocated
buffer with data (which is of limited size) and the other create a
new buffer. There might be two independent API-calls for this.
Seek
Tell
Seek uses a pair of two INTVALs (lo,hi), whereas tell returns a
PIOOFF_T. Both calls should use PIOOFF_T.
-> Change signature of Seek
SetLineBuf
I don't think this belongs here. Linebuffering should be a layer on
top of the existing layers. SetLineBuf will then be
PIO_push_layer(interpreter, io, line_buf_layer);
-> Remove this from API
GetCount
Fill
What should these calls do?
Poll/Select
Some function like this should be entered. But this call needs a
seperate diskussion
Comments?
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
Gregor N. Purdy
Juergen Boemmels wrote:
> Write
> PutS
> Why are there two diffrent calls to write data to an io, with only a
> slightly different prototype. This is code-duplication in every
> layer. I can't think of any use case where PutS won't be implemented
> as Write(..., data, strlen(data)). These two calls could be unified.
> As a side note: The primary memory structure is the buffer, maybe
> the unified call should take a buffer argument.
> -> unify these two
We need to be careful here about the difference between C strings and
Parrot strings. For your basic C string strlen(data) is the way to
decide how many bytes to write. For Parrot strings, we can have
internal zero bytes (or the lack of a trailing zero byte) that will
throw off strlen and therefore screw things up.
I have a patch on my workstation (currently in transit from Cincinnati
to Seattle, so not accessible -- but, I've discussed a bit with Dan on
IRC) that tries to deal with this issue by having a "*c" (for C-style)
and a "*l" (for length-style) variant of a couple functions (including
changes to vtables stuff, IIRC).
But, that leaves out another important piece: If we have a Parrot string
in some encoding, and we are going to Write/Put it to STDOUT, which is
headed for someone's terminal, we might need to do more than just blast
the buffer if we expect the user to do anything other than curse us and
our mothers.
Regards,
-- Gregor
Juergen Boemmels
"Gregor N. Purdy" <gre...@focusresearch.com> writes:
> Juergen --
>
> Juergen Boemmels wrote:
>
> > Write
> > PutS
> > Why are there two diffrent calls to write data to an io, with only a
> > slightly different prototype. This is code-duplication in every
> > layer. I can't think of any use case where PutS won't be implemented
> > as Write(..., data, strlen(data)). These two calls could be unified.
> > As a side note: The primary memory structure is the buffer, maybe
> > the unified call should take a buffer argument.
> > -> unify these two
>
> We need to be careful here about the difference between C strings and
> Parrot strings. For your basic C string strlen(data) is the way to
> decide how many bytes to write. For Parrot strings, we can have
> internal zero bytes (or the lack of a trailing zero byte) that will
> throw off strlen and therefore screw things up.
I'm not arguing for removing PIO_puts et al., I want to remove
ParrotIOLayerAPI.PutS. Both calls Write and PutS take a pointer to raw
data; the first one with a len, the second one with terminating
'\0'-byte. There is no version which takes a Parrot-String with
encodings.
A unified version of ParrotIOLayerAPI.Write might have the signature
Write(struct ParrotInterp *, ParrotIOLayer *, ParrotIO *, Buffer *);
> I have a patch on my workstation (currently in transit from Cincinnati
> to Seattle, so not accessible -- but, I've discussed a bit with Dan on
> IRC) that tries to deal with this issue by having a "*c" (for C-style)
> and a "*l" (for length-style) variant of a couple functions (including
> changes to vtables stuff, IIRC).
>
> But, that leaves out another important piece: If we have a Parrot string
> in some encoding, and we are going to Write/Put it to STDOUT, which is
> headed for someone's terminal, we might need to do more than just blast
> the buffer if we expect the user to do anything other than curse us and
> our mothers.
This is another problem. Should this recoding be done in the
IO-subsystem? This data-recoding might be another layer on top of the
others. But then the Parrot-String must be passed down to the
layers. This demands even more a unified version, because the current
version does not pass this information down.
bye
Nicholas Clark
> GetCount
> Fill
> What should these calls do?
These look like they are for buffering layers.
For a long time the perl5 tried to "cheat" stdio by sneaking data directly
out of the stdio buffers. To do this, it was trying to keep track of
the count of how many bytes remained, and using getchar() or somesuch to
get the buffer refilled.
The PerlIO system implemented for 5.8 has a fill method to explictly refill
the buffer of the layer you are reading from, and Get_ptr and Get_cnt
to get the current pointer and remaining byte count of the buffer.
If perl5 can't figure out stdio, it doesn't "cheat" on it. Curiously
when I taught Configure how to figure out glibc stdio, the relevant
perlbench test speeded up enormously. When I taught it to cheat on
FreeBSD stdio, there was no difference.
Maybe I'm jumping to conclusions based on insufficient data, but
I'd hope that a well designed buffer read API would be fast enough to
avoid need for these buffer snooping games.
I'm hoping that we can use sufficiently "regular" buffers that we can
copy on write all the way up the stack from the kernel read to the
PMCs presenting data at language level, so that for read only grepping
of files there is no data copying at all. (And hopefully the file at the
bottom is memory mapped)
Nicholas Clark