Re: port initialization?

[Han-Wen Nienhuys]

address@hidden writes:
> > >Yes, but the GC will not notice since "z" still refers to it and
> > >therefore the port cell wont be freedo
> > 
> > That's not what I meant: z is a heap cell containing a null
> > pointer. GC-ing it will dump core.
> 
> Sure?  Closed ports do contain NULL pointers as well and the GC can
> handle them just fine.  The second word of a cell that is tagged as a
> port is not a SCM.  The GC knows that and will not try to follow it
> (except when freeing a port cell but then only when it is not flagged
> as closed).  Am I missing somthing?

Perhaps I'm missing something. I think that having null pointers in
the heap is not a good idea, but of course you're right (just
checked), there are lots of checks to prevent a core dump.

> > > >         SCM port = scm_cell (scm_tc16_port, newport);
> > > >         newport->port = port;
> > > >                       ..
> > > >     }
> > > /
> > > This will leak newport when the call to scm_cell throws.
> > 
> > scm_cell throws, what do you mean?
> 
> I meant, when we run out of memory.  Does scm_cell signal an error
> then (als scm_misc_error), or does it just abort the process?

All errors in the GC cause an abort(), AFAIK.

(checking)

No, there are some out-of-memory errors, and scm_misc_errors, mainly
for programming errors (rogue pointer, undefined smob type, etc.). I
think that this is a bad idea. Unwinding the stack (which is done in
scm_error, right?) wlil stop the GC halfway. I think this will lead
unpredictable results.

An out-of-memory error should be handled gracefully, I would says
although I can't really imagine how (there is little code that can
run, if you can't alloc a string or a cell, right?)


-- 
Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen