Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Fri, May 28, 2004 at 11:38:55AM +0200, Leopold Toetsch wrote:
>> The returned string gets malloc(3)ed. >> PObj_external_FLAG|PObj_sysmem_FLAG is set, so that the memory gets >> freed during DOD. > I can't find your earlier proposals (which suggests that I've read and > deleted them), so I may be missing something from there. It was about changing ParrotIOLayerAPI Write() to get a STRING* passed (done) and PIO_read to return a STRING*. The interface is/was written in terms of passing (buffer*, len) pairs. The problem (mainly with readline) is, that the length that Read() needs isn't known in advance. The C<readline> opcode currently allocates 64K :( And of course: a STRING* should hold information about the "encoding" of the string so that conversion layers can properly act on the data. > Why does the memory need to be malloc()ed, rather than grabbed from something > parrot can pass onwards through PMCs? A io_mmap layer could just make a STRING* point to the external memory. But for read(2) or fread(3) we need some storage for the read data. Instead of malloc()ing the memory we could use Parrot_allocate_string() too. The thing that's passed on is always a STRING*. It doesn't really matter, ... > ... Is the intent to keep the IO system > isolated from most of parrot, so that it still works during VM > setup/teardown? ... except exactly because of that. The IO subsystem is currently initialized in two steps. PIO_init() is called twice, doing a step by step initialization. Destroying is still more nasty. Dying threads have to clean all their alloced resources. STDIO handles are shared AFAIK. And the last interpreter that's getting destroyed has to cleanup, if --leak-test is given on the commandline. To simplify interpreter destruction the PIO destroy stuff should better be done in a F<finalize> vtable. > Am I guilty of premature optimisation here? Hmm. Dunno. Dan's event draft mentions that IO layer code may run in different threads. This would need shared PerlStrings for IO data. I don't know if that's really desirable--or I doubt it. So let's say: memory is currently malloced. Doing the same with STRINGs has the lowest impact on possibly breaking something :) > Nicholas Clark leo
