Guile Mailing List Archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upcoming 1.3.2 release



Greg Harvey <Greg.Harvey@thezone.net> writes:

> The problem isn't so much that it could be problematic to call scheme
> code, but pretty much anything in guile is suspect (except scm_cons &
> newcell, because we know that'll screw things up). A set of predefined
> behaviours could work, but you'd want to watch out for something like
> the second, since you can't reliably call things like display & stuff
> like that... you could do writes on the underlying fd, if you don't
> have to worry about buffering (or don't care about slightly odd
> output), though. I'll add a bit to allow registering c functions to
> my gc code, but I do think it'd be a really bad idea to add a general
> hook for this.

Sorry for not noticing the implications.

However, I do like the idea of using hooks from all other aspects.
And I think it's a good idea to try hard to get rid of extra
mechanisms for specific purposes.

What about reserving a pool of conses which is made available to
NEWCELL during special conditions like this?  (There's still the
problem with malloced memory.)  The size of this pool could be a
settable parameter.

Also, note that if only well-behaved C functions, wrapped as
scm_tc7_subr_0:s, are added to before-gc-hook, no conses will be used,
so it's still possible to use the hook mechanism.

Guile Home | Main Index | Thread Index