[RfC] Semantics of clone for PIO-objects.
Juergen Boemmels
On some systems t/pmc/io_6.pasm fails because of a double free. The
problem is that the clone call adds a reference to ParrotIO object,
but the ParrotIO object is neither garbage collected nor refcounted so
it gets destroyed when its first refrence is destroyed.
The solution of that memory problem is simple: just allocate a new
ParrotIO in the clone call.
But what should be the semantics of the cloned IO object?
What happens with interleaving writes?
clone P1, P0
print P1, "Hello"
print P0, "World"
First come, first serve seems right to me here.
What about buffered io? Should the clone call flush the buffer, will
the new object just get an empty buffer or even copy over the buffer
data (this would lead to double output of the buffer).
What happens to seek/tell. Should every object have its own file
position pointer or should these be shared like in dup.
What is the semantics of double close. First close wins or last close
wins.
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
Jos Visser
> Comments
My first hunch is to see the ParrotIO object as a channel of data into
an underlying file (leaving "channel", "data", and "file" vaguely
defined for now)... This would mean that every ParrotIO object has its
own file pointer, but all copies show the exact same view of the file
(this would imply splitting the ParrotIO layer and performing buffering
in the lower/shared layer).
Then, cloning a ParrotIO object would mean creating a new ParrotIO
object that points to the same file (through the same lower/shared
representation of the file), and starts out with the same file location.
If we then write the file through P0, the data goes to the file
(buffered if necessary), but moves the logical file pointer of P0 only!
Writing to P1 would then overwrite the data just written by P1. If you
don't want that, you could call some methods to set the file pointer of
P0 to the same value as that of P1.o
Closing a ParrotIO object would close that channel into the data only.
When the last reference (reference counting! Yipiie!) to the underlying
file is closed, the lower/shared layer representation of the file would
be closed.
My 2 cents...
++Jos.es
--
ek is so lug jy vlieg deur my
sonder jou is ek sonder patroon
"Breyten Breytenbach"
Leopold Toetsch
> As the semantic of the clone-call is not clear yet can some-one please
> apply this patch
Done, thanks.
> bye
> boe
leo